Patent Application
20180203654
The present invention generally pertains to a method for generating a preview image of an image in a print job for displaying in a user interface of a print system.
The present invention further provides a computer program product implementing such method.
The present invention also provides a printer controller that generates a preview image of an image in a print job.
The present invention further provides a print system that comprises such printer controller.
It is known to generate previews and thumbnails of images to be printed by the raster image processor (RIP) of a print system.
Thumbnails serve in general to be displayed in a user interface to allow quick visual identification of images, pages, print jobs, etc. They generally have a low resolution as they are to be displayed along various other elements in the user interface such as texts to further identify the images, pages, print jobs, etc., properties of the images, pages, print jobs, etc., and controls for controlling the print system, setting and changing properties of the images, pages, print jobs, etc.
Previews may serve the same purposes as thumbnails, but previews may also be used to preview the effect of certain settings such as job settings, print settings, etc. Previews typically still have a lower resolution than the native print resolution although it is possible that a preview is generated at the native print resolution, but with settings serving the preview process (for example display hardware typically uses a red-green-blue colour space while print engines typically use a cyan-magenta-yellow-key colour space).
Previews and thumbnails have in common that they need to be available before the image to be printed is actually printed by the print engine in order to allow the user of the printing system to set print properties for a print job, set properties for the processing of individual pages or images to be printed and preview the effect of such settings before the print engine actually starts printing the print job comprising the pages or images. Furthermore, they need to be available without any major delay once requested by the user interface of the print system. If this is not the case, the user of the print system may perceive the user interface as unresponsive or at least badly responsive. Furthermore, usually they have in common that they are to be generated at a lower resolution than the native print resolution resulting in their generation times generally being significantly lower than the generation time of the raster images to be printed, which are at the native print engine resolution.
For the sake of conciseness, previews and thumbnails will, in the remainder of this document, collectively be referred to as previews unless specifically denoted otherwise.
In simple RIP architectures (single raster image processor core), previews may be generated on demand. In such an architecture, the delay for generating the preview comprises of course the generation of the preview itself, but if the RIP is already occupied by the generation of a raster image for printing purposes, an additional delay is introduced for the RIP to finish the generation of the image it is already working on. For cut sheet printers this delay may in some cases still be acceptable, but for wide format printers, this delay will quickly become an issue given the much larger images to be rasterised. In cases where the architecture uses a queueing mechanism to queue images to be processed in the RIP, either the preview images will have to wait until all earlier images in the queue have been processed first, which will generally result in unacceptable delays in the user interface, or some priority system should be implemented to allow the preview images to bypass the queue in order to be processed earlier. Such a priority system makes the queueing system more complex though.
In parallel RIP architectures with four or more RIP instances, one solution employed is to have one RIP instance dedicated to the generation of preview images. Although this guarantees there are always processing resources for the generation of preview images, it also means that when the print engine is running for a long time unattended, for example during unattended overnight production, the RIP is not used optimally, because one of the RIP instances is sitting idle for a long time. In the case of a RIP with four RIP instances, only 75% of the RIP resources is used during such periods.
The object of the present invention is to overcome or at least mitigate these disadvantages of the prior art.
In a first aspect of the present invention, a method is provided for generating a preview of an image in a print job comprising the steps of: creating a preview RIP-job at the head of a RIP-job queue, the RIP-job queue queueing in first-in-first-out order RIP-jobs to be submitted to and processed by a raster image processor, and the preview RIP-job arranged to register images to be submitted to the raster image processor for generating a preview of the image, registering the image in the preview RIP-job in order for the image to be submitted to the raster image processor, wherein the completion of the preview RIP-job is independent of the state of any print job as well as independent of the contents of the preview RIP-job.
The preview may be a low resolution image for identifying a print job in the print queue of the printer controller, identifying a page or image to be printed in a print job, or a preview image with a resolution that is typically lower than the native print engine resolution that is intended to be used in the user interface of the printer controller for previewing purposes, i.e. allowing the user to check prior to printing whether the image is rendered as intended by the user and does not contain undesired artefacts.
Pages in this context refer to pages in the traditional sense, such as pages processed in a cut sheet printer (each side of a sheet corresponding to a page), but also refers to individual images printed on a role, web, or large format sheet printed on a table printer, wherein the individual images are intended to be separated from each other by cutting, or folding combined with trimming, or similar techniques, i.e. the pages resulting from dividing a larger sheet into smaller sheets. In this context pages and images to be printed are synonymous.
The preview RIP-job behaves in the RIP-job queue just as any other RIP-job. Upon creation it is created at the head of the RIP-job queue. Due to the first-in-first-out behaviour of the RIP-job queue images registered in the preview RIP-job are automatically processed by the raster image processor before any images that are registered in any other RIP-job without any need for the implementation of a specific priority scheme in the RIP-job queue or in the RIP-jobs themselves or alternative ways to have preview images bypass other images to be ripped. This way the raster image processor is always first fed with images from the preview RIP-job, therefore making sure that images intended to be used in the user interface are always processed first resulting in a more responsive user interface.
Note that the verb “rip” is used inhere to refer to the activity of the raster image processor generating raster images provided in a Page Description Language (PDL).
Preview images that are intended to be used in the user interface are queued by a user interface generation device in the preview RIP-job, while images intended to be printed by the print engine are queued in any other RIP-job.
Registering a page in a RIP-job may comprise storing the actual content of the page (for example a page description in a PDL), but preferably comprises storing a page identifier or other reference to the page. Note that any means of associating a page with a RIP-job s suitable.
The preview RIP-job will not be removed from the RIP-job queue if the preview RIP-job becomes empty. Nor will it be removed from the RIP-job queue due to other RIP-jobs becoming empty or being completed. The state of any other RIP-job or print job is irrelevant. Basically, the only reason to remove the preview RIP-job from the RIP-job queue is as part of a shutdown process or restart or reinitialisation process of the printer controller or part of the printer controller.
Note that a RIP-job becoming empty in general is not necessarily a trigger to remove the RIP-job from the RIP-job queue. As described further on dedicated mechanisms may be implemented to control when a RIP-job may be removed from the RIP-job queue, the RIP-job being empty being only one condition to be met.
In order to ensure that the preview RIP-job is created at the head of the RIP-job queue, a dedicated creation mechanism may be implemented for the preview RIP-job. However, in order to keep the implementation simple, in a preferred aspect of the invention the preview RIP-job is created at the head of the RIP-job queue by creating the preview RIP-job before any other RIP-job is queued. This way the preview RIP-job is automatically at the head of the RIP-job queue due to the first-in-first-out behaviour of the RIP-job queue.
In a further aspect of the invention the preview RIP-job is created during system start-up, for example during initialisation of the RIP-job queue. This ensures that no RIP-jobs are present in the RIP-job queue and the preview RIP-job ends up at the head of the RIP-job queue and does not require dedicated mechanisms to allow for the queueing of an object at the head of the queue.
In one aspect of the present invention the method further comprises the steps of: a) checking whether a number of ripped but unprinted images is below a first predetermined threshold, b) checking whether a number of unripped images in RIP-jobs other than the preview RIP-job exceeds a second predetermined threshold, and c) suspending submission of an image to the preview RIP-job as long as the conditions of both steps a) and b) are met. This ensures it is not possible to make the print process starve due to a large number of preview images to be generated while there are also images to be ripped to feed the printing process. The thresholds allow for balancing between preview image generation and ripping to feed the printing process (ripping to produce raster images for the print engine). Note that any or both of the thresholds may be chosen to be zero.
In one aspect of the present invention a preview is displayed in a user interface.
The present invention provides a computer program product embodied on a non-transitory computer readable medium that, if executed on a processor, performs any of the methods as described above.
According to another embodiment the present invention provides a printer controller arranged to control a print engine, the printer controller comprising: a print job reception device; a RIP-job generator connected to the print job reception device and arranged to determine at least one RIP-job for the print job, wherein the RIP-job is arranged to register images in a page description language; a raster image processor for generating a raster image for an image provided to the raster image processor in a page description language; a RIP-job queue connected to the RIP-job generator and to the raster image processor, and arranged to receive RIP-jobs from the RIP-job generator, queue the RIP-jobs in a first-in-first-out order, and provide an image from the first non-empty RIP-job starting from the head of the RIP-job queue to the raster image processor; wherein the printer controller is further arranged to: create a preview RIP-job at the head of the RIP-job queue; and register images to be previewed in the preview RIP-job; and wherein the completion and dequeueing of the preview RIP-job is independent of the state of any print job as well as independent of the contents of the preview RIP-job.
The print job reception device may comprise logic to receive print jobs from workstations connected to the printer controller through a network. The print job reception device may also comprise logic to receive a print job internally created in the controller for example in the context of a copy job comprising of a scan job and a corresponding print job, or in the context of a new print job being created in the printer controller by deriving the new print job from an existing print job.
According to a further embodiment the present invention provides a printer controller wherein the preview RIP-job is created at the head of the RIP-job queue by creating the preview RIP-job before any other RIP-job is queued.
According to a preferred embodiment a printer controller is provided wherein the preview RIP-job is created during system start-up.
According to another embodiment the present invention provides a printer controller further arranged to: a) check whether a number of unprinted raster images is below a first predetermined threshold, b) checking whether a number of images in RIP-jobs other than the preview RIP-job exceeds a second predetermined threshold, and c) suspending submission of an image to the preview RIP-job as long as the conditions of both steps a) and b) are met.
In another embodiment according to the invention a printer controller is provided that further comprises a user interface generation device, wherein the printer controller is arranged to: submit an image from a print job that is to be previewed through the user interface to be generated by the user interface generation device to the preview RIP-job; and have the corresponding raster image generated by the raster image processor provided to the user interface generation device. The generated preview image is subsequently displayed on a display device to allow the user to view the preview image.
According to another embodiment the invention provides a print system comprising a print engine for forming an image on a media by depositing marking material on the media, the print system further comprising the print controller as described above, wherein the print controller is connected to the print engine and is arranged to provide a raster image to be printed to the print engine and to control the print engine in order to have the print image form the image on the media.
Further scope of applicability of the present invention will become apparent from the detailed description given hereinafter. However, it should be understood that the detailed description and specific examples, while indicating embodiments of the invention, are given by way of illustration only, since various changes and modifications within the scope of the invention will become apparent to those skilled in the art from this detailed description.
The present invention will become more fully understood from the detailed description given hereinbelow and the accompanying schematical drawings which are given by way of illustration only, and thus are not limitative of the present invention, and wherein:
The present invention will now be described with reference to the accompanying drawings, wherein the same reference numerals have been used to identify the same or similar elements throughout the several views.
A typical reprographic apparatus (
The engine 120 is responsible for low-level control of the apparatus. It deals with individual hardware components that are responsible for the reprographic process such as drives for media transport, media detectors (in the media path as well as in the input and output media trays), path switches, fusers, print heads, etc.; in general actuators and sensors 128. These actuators and sensors are connected through input/output (I/O) boards 127 to a bus 129. The bus 129 connects the major components in the engine 120. Actual data processing takes place in a central processing unit (CPU) 121. The CPU 121 reads sensor values from the sensors 128 through the I/O 127. Based on these sensor values and other data such as print data and print commands received from the controller 110, the CPU 121 determines how the engine 120 should respond to this information and determines appropriate actuation values that are sent through the I/O 127 to the actuators 128. The engine 120 comprises a volatile memory such as a random access memory (RAM) 122 to temporarily store data for processing such as the print data and print commands received from the controller 110, and the sensor values read from the sensors 128. Furthermore, a non-volatile memory such as a hard disk drive (HDD) 123 serves to store data in a more permanent manner, for example to survive a power down of the system. This hard disk drive 123 typically also stores embedded software comprising computer instructions that are run on the CPU 121. The engine 120 typically runs a real-time Operating System (RTOS), for example a soft real-time Operating System in order to deal with the time critical functions of controlling the actuators 128. The engine 120 further comprises a communication device 124 to communicate with the controller 110. Typically, the engine 120 receives print data and print commands from the controller 110 and provides back status information on the engine 120 itself and on the processing of the print commands and print data, including sending error messages to the controller 110.
The controller 110 is connected to the engine 120 through a communication device 114 that communicates with the communication device 124 of the engine 120. These communication devices 114, 124 may be implemented as Ethernet network interface controllers (NIC). Processing in the controller 110 is done by a CPU 111 that is connected to all the other components in the controller 110 through a bus 119. The data to be processed is temporarily stored in a volatile memory such as RAM 112, while data is stored in a more permanent manner in a non-volatile memory such as hard disk drive 113, for example in order to survive power downs, but also to relieve the volatile memory 112 which typically has a smaller storage size. The hard disk drive 113 typically stores print jobs, each comprising print data and a job ticket. Furthermore, the hard disk drive 113 comprises converted print data which is print data converted to a format suitable for processing by the engine 120. Typically the converted print data comprises raster images. Converting the print data in the print jobs to converted print data is typically done in a Raster Image Processor (RIP). Although the RIP may be a dedicated hardware device, it is common to be implemented in software and running on CPU 111. As the RIP-process is rather computationally intensive, it is common for controllers 110 to have multiple processing units in the form of a multi-core CPU 111 or multiple CPUs 111. The controller 110 further comprises a display 116 to show messages to an operator, or display a complete graphical user interface (GUI) to an operator for operating the reprographic apparatus. The display 116 is supplemented by a human interface device (HID) 118 such as a keyboard, mouse, touchpad, stylus, or touch sensitive panel integrated into display 116, and allows the operator to operate the reprographic apparatus. The controller 110 comprises a communication interface 117 for communicating with peripheral devices such as finisher, for example, stackers, staplers, binders, punchers, cutters, trimmers, folders, media input units, etc. The controller 110 further comprises a network interface card (NIC) 115 to connect the controller 110 to a computer network. Through the network connection, print jobs may be submitted to the controller 110 and the results of scan jobs may be retrieved from the controller 110. For these operations the controller 110 may be directly in communication with individual workstations, or indirectly through a print server. Furthermore, the network connection may be used to remotely operate the reprographic apparatus, monitor its status, and send production data to monitoring systems, accounting systems, or business information systems. Note that in smaller printer models, specifically printers suitable for placement on desks, it is common to use communication interfaces such as USB, FireWire, or Bluetooth instead of the NIC 115.
The controller 110 and the engine 120 may be implemented in a single printer device (typical for smaller printers for low volume printing), or as two separate, but interconnected devices (typical for larger, high-volume production printers).
The engine 120 typically deals with print data on a sheet level, swath level, or even line level. The engine 120 is generally not aware of information on a document or even job level. In contrast the controller 110 receives print jobs comprising one or more documents. In the case of cut sheet printers the documents typically comprise multiple pages.
The images to be printed are typically provided to the printer formatted according to a Page Description Language (PDL). Although the word ‘page’ in ‘Page Description Language’ may suggest that a PDL is specifically applicable to cut sheet printers, this is not the case. PDLs are also used to submit images to be printed to roll printers, web printers, table printers, etc., or to the controllers of such printers. Furthermore, the word ‘image’ in this document refers to data describing in some format an intended image to be printed on the printer. The print data may be formatted in varying forms, for example a description of a rasterised image in the TIFF (Tagged Image File Format) format, but also in the form of object descriptions, such as a rectangle with given or implied properties such as dimensions, position, orientation, and colour, or a text string with given or implied properties. The raster image processor will take this print data and generate a print engine specific raster image. In here such print engine specific raster images will generally be referenced as ‘raster images’. Even if the print data is provided as a rasterised image or contains a rasterised image, the raster image processor generally still has to generate the print engine specific raster image for such a rasterised image in order to take into account the particular imaging process of the print engine. In cut sheet printers the rasterised image generated by the raster image processor typically corresponds to all content to be printed on a single page (one side of a sheet) by the print engine.
In a typical embodiment the invention is implemented in the controller 110 of a reprographic apparatus such as a printer. Jobs entering the system may be created locally, for example in the case of a copy job the controller may first spawn a scan job followed by a print job that is created based on the scan data obtained from the scan job. Alternatively, the job may be created remotely, for example in a remote workstation submitting a print job through a printer driver. In both cases, the new job is being initially handled by a job reception module such as the print job reception module 212 (
As described above, the RIP-job queue 218 serves to queue RIP-jobs 330-332 (
Once a RIP-job 330-332 is empty, it is not necessarily removed from the RIP-job 218 until it has been determined that the RIP-job has been completed, as the RIP-job generator 216 may still have images 351-358 to queue for this RIP-job 330-332. This may be realised by the RIP-job generator 216 setting a ‘complete’ property on the RIP-job 330-332 once it has determined that there are no more images 351-358 to assign to the particular RIP-job 330-332. Then the RIP-job 330-332 is removed from the RIP-job queue 218 once it has been determined that the RIP-job 330-332 is empty and the ‘complete’ property is set.
If a processor of the raster image processor 224 is available and the RIP scheduler 222 is determining the next image 351-358 to process, it may find an empty RIP-job 330 at the head 362 of the RIP-job queue 218. In that case, it will simply move on to the next position, position 1, in the RIP-job queue 218 and so on, to find a RIP-job 330-332 that contains an image 351-358 to be processed. This allows the raster image processor 224 to keep on processing even if earlier RIP-jobs 330-332 in the queue are not ready to be processed first. This is advantageous as usually the process of rasterising images into print engine specific raster images is computationally the most demanding process in a printer.
In order to allow previews to be generated, an embodiment according to the present invention has a dedicated preview RIP-job 330 and this dedicated preview RIP-job 330 is created at the head 362 of the RIP-job queue 218. Dedicated means in this context that the RIP-job 330 is not used to queue images for rasterising for printing purposes to the native print engine resolution as those rasterisaton process are typically computationally much more expensive. Furthermore, creation of previews is a more or less continuous thing as long as the printer is operational allowing for previews to be generated for newly created print jobs. Therefore, the ‘complete’ property on the dedicated preview RIP-job 330 is not set unless the printer is for example commanded to shut down or to restart. In any case, the completion status of the dedicated preview RIP-job 330 is not dependent on the completion or state of any specific print job or other RIP-job 331-332.
The queuing of previews may be done according to the flow chart in
Processing the images 351-358 waiting in RIP-jobs 330-332 by the RIP scheduler 222 is illustrated in the flow chart of
Note that the process in
The easiest way to ensure that the preview RIP-job 330 is created at the head 362 of the RIP-job queue 218 is to make the creation part of the creation/initialisation process of the RIP-job queue 218 (see
The invention allows for generating previews of images 351-358 through the same Raster Image Processor 224 as used for generating full page-size images at the print engine's native solution and the generation of the previews to be responsive without the RIP-job queue 218 having explicit support for prioritised jobs.
As images 351-352 in the preview RIP-job 330 are always processed before the images 353-358 in the ordinary RIP-jobs 331-332, it is possible to bring the ripping of images for printing to a halt by flooding the preview RIP-job 330 with images.
This may happen if the preview images for thumbnails are queued for ripping upon reception of the print job (so prior to the user interface actually needing the thumbnails) and one or more print jobs with many pages is received. It takes quite a number of queued images 351-352 for this to happen though as the thumbnails in the user interface typically have small sizes and ripping to small images takes considerably less time than ripping to full page-sized bitmaps at the native print engine resolution. This issue is less prominent when the previews are requested by the user interface on demand, as there typically only fit a limited number of thumbnails on the display of the device. Furthermore, in the case of generating preview images for previewing purposes, this issue does usually also not occur as such preview images are typically requested on demand and a user may typically only preview a single image (single page) or two images (two-page spread preview) at a time. However, occurrence of this issue may be prevented forcedly by imposing a constraint on the number of preview images 351-352 the preview RIP-job 330 will accept (for example hard limit on queue length), on the number of preview image requests the user interface will have pending simultaneously, or on the rate with which the user interface submits preview images 351-352. Note that implementing such constraints will increase print engine productivity at the expense of reduced user interface responsiveness.
Detailed embodiments of the present invention are disclosed herein; however, it is to be understood that the disclosed embodiments are merely exemplary of the invention, which can be embodied in various forms. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a basis for the claims and as a representative basis for teaching one skilled in the art to variously employ the present invention in virtually any appropriately detailed structure. In particular, features presented and described in separate dependent claims may be applied in combination and any advantageous combination of such claims is herewith disclosed.
Further, the terms and phrases used herein are not intended to be limiting; but rather, to provide an understandable description of the invention. The terms “a” or “an”, as used herein, are defined as one or more than one. The term plurality, as used herein, is defined as two or more than two. The term another, as used herein, is defined as at least a second or more. The terms including and/or having, as used herein, are defined as comprising (i.e., open language). The term coupled, as used herein, is defined as connected, although not necessarily directly.
The invention being thus described, it will be obvious that the same may be varied in many ways. Such variations are not to be regarded as a departure from the spirit and scope of the invention, and all such modifications as would be obvious to one skilled in the art are intended to be included within the scope of the following claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 17151680.0 | Jan 2017 | EP | regional |
This application claims priority under 35 U.S.C. § 119(a) to Application No. 17151680.0, filed in Europe on Jan. 16, 2017, the entire contents of which is hereby incorporated by reference into the present application.
