Printing operation management method and printing system using intelligent rip I / O for printing operation

Abstract

To provide a printing operation management method which can surely and efficiently print a page by RIP.SOLUTION: A front end of a raster image processing (RIP) system determines a start storage place and a storage hierarchy. The hierarchy determines a place where a rendering page of a job is stored. At least one page of pages of a first set of the job is stored in a memory of the RIP system. When the memory is not available, at least one page of pages of a second set of the job is stored in a storage drive. It is determined whether the rendering page of the job is stored in the storage drive depending on the kind of the job. A complicated page is also stored in the storage drive, and a simple page is discarded. Processing operation is managed to efficiently operate a printing engine.SELECTED DRAWING: Figure 5

Description

[Technical field]

[0001] The present invention relates to a printing system and related methods that use a hierarchy of storage drives to provide input / output (I / O) for a Raster Image Processor (RIP) that processes various print jobs. [Background technology]

[0002] Traditionally, RIPs store all rendering data on disk.

[0003] Patent Document 1 describes an image input / output device that can properly execute image processing operations in a multifunction peripheral equipped with a large-capacity hard disk even when the hard disk cannot be used for some reason. The device in Patent Document 1 includes a page memory that temporarily stores image data and a hard disk that stores the image data temporarily stored in the page memory, and divides one unit of image processing to be executed into an image input job that inputs image data from an image input unit and an image output job that outputs image data to an image output unit, and executes multiple units of image processing in parallel by independently controlling the execution of the image input job and the image output job, while prohibiting the operation of executing multiple units of image processing in parallel in response to detection of an abnormality in the hard disk.

[0004] Also, typical techniques include storing the data on disk, thereby ensuring a buffer of rendered data that is readily available to ensure printing continuity even when the processing times for different job pages vary considerably. While this may be sufficient in some cases, this process can become problematic for large jobs that may generate terabytes of rendered data. Such amounts of rendered data can stress the I / O subsystem and limit overall system performance. To address this issue, some RIPs eliminate I / O operations entirely by streaming the rendered data from memory to the printhead without an I / O buffer (hereafter referred to as the "prior art"). [Prior art documents] [Patent documents]

[0005] [Patent Document 1] JP 2000-138787 A Summary of the Invention [Problem to be solved by the invention]

[0006] However, in the conventional techniques described above, while performance of large jobs may be improved, it was necessary to define hardware that could process the largest job at the speed of the print engine. However, it was inefficient to define the hardware specifications around the most complex pages in the job, which may be a small number of pages in the job. Therefore, there was a possibility that there may be pages that the hardware could not process at the speed of the engine.

[0007] The present invention has been made in view of the above circumstances, and has an object to solve the above-mentioned problems. [Means for solving the problem]

[0008] A method for managing print operations is disclosed. The method includes receiving a print job having a plurality of pages. The method also includes rendering at least one page of a first page set of the plurality of pages from the print job using a raster image processor (RIP) system. The method also includes storing the rendered at least one page of the first page set in a memory at a printing device receiving the print job. The method also includes determining that the memory is unavailable. The method also includes rendering at least one page of a second set of pages of the plurality of pages of the print job using the RIP system. The method also includes rendering at least one page of the second page set of the plurality of pages of the print job using the RIP system. The method also includes storing the rendered at least one page of the second page set in a first storage drive of a hierarchy of storage drives accessible by the printing device. The first storage drive has a larger capacity than the memory. A method of managing print operations is disclosed. The method includes rendering at least one page of a first page set and at least one page of a second page set of a print job by a raster image processor (RIP) system. The method also includes storing the rendered at least one page of the first page set in a memory accessible by the RIP system. The method also includes determining that the memory is unavailable. The method also includes storing the rendered at least one page of the second page set in a first storage drive in a hierarchy of storage drives accessible by the RIP system. The first storage drive has a larger capacity than the memory. The method also includes determining that the at least one page of the first page set in the memory has been printed by the printing device. The method also includes deleting the at least one page of the first page set from the memory. The method also includes storing further rendered pages of the print job in the memory. A method for managing print operations is disclosed. The method includes receiving a print job having a plurality of pages to be printed by a printing device. The method also includes rendering a first page of the plurality of pages by a raster image processor (RIP) system of the printing device. The method also includes determining whether the first page is a complex page or a simple page. The method also includes storing the rendered first page in a memory within the printing device if the first page is a simple page. The method also includes storing the rendered first page on a first storage drive in a hierarchy of storage drives accessible by the RIP system if the first page is a complex page. The first storage drive has a larger capacity than the memory. A method for managing printing operations is disclosed. The method includes receiving a print job having a plurality of pages to be printed at a printing device. The method also includes creating a hierarchy of storage drives for the plurality of pages to be stored. The method also includes rendering the plurality of pages with a Raster Image Processor (RIP) system for the printing device. The method also includes determining, in response to a job type of the print job, to defer printing of the print job to a subsequent time period. The method also includes storing the rendered plurality of pages in a first storage drive of the hierarchy of storage drives accessible by the RIP system in response to the job type. The first storage drive has a larger capacity than memory accessible by the RIP system. A method for managing print operations is disclosed. The method includes receiving a print job having a plurality of copies to be printed on a printing device. The method also includes creating a hierarchy of storage drives on which the plurality of pages are to be stored. The method also includes rendering the plurality of pages to a first storage drive accessible by a RIP system. The first storage drive has a larger capacity than memory accessible by the RIP system. The method also includes communicating that the rendered plurality of pages are stored on the first storage drive. The method also includes retrieving the rendered plurality of pages from the first storage drive by an engine manager of the RIP system. The method also includes printing a copy of the plurality of copies of the print job using the rendered plurality of pages. The method also includes determining that a final copy of the plurality of copies of the print job is to be printed. The method also includes deleting the rendered plurality of pages from the first storage drive. A method for managing print operations is disclosed. The method includes rendering a print job having a plurality of pages in a Raster Image Processor (RIP) system for a printing device. The method also includes receiving an instruction to interrupt rendering of the print job. At least a first page of the plurality of pages is rendered by the RIP system and stored in a memory accessible by the printing device. The method also includes storing the at least one first page on a first storage drive accessible by the printing device. The method also includes deleting the at least one first page from the memory. A method for managing print operations is disclosed. The method includes receiving a print job having a plurality of pages to be printed at a printing device. The method also includes determining that an amount of storage space in a storage location is not available to store the rendered plurality of pages of the print job. The rendered plurality of pages are processed by a Raster Image Processor (RIP) system. The method also includes, for each page of the plurality of pages, determining whether the page is complex. The method also includes, for each page of the plurality of pages, adding the page to be stored with the rendered plurality of pages if the page is complex. The method also includes, for each page of the plurality of pages, removing the page from the rendered plurality of pages if the page is not complex. The method also includes storing the rendered plurality of pages in a storage location accessible by the RIP system. A method for managing print operations is disclosed. The method includes receiving a print job having a plurality of pages at a printing device. The method also includes determining that an amount of storage space in a storage location is not available to store the rendered plurality of pages of the print job. The rendered plurality of pages are processed by a Raster Image Processor (RIP) system. The method also includes determining, for each page of the plurality of pages, a rendering time of the page in the RIP system. The method also includes adding the rendered page to the rendered plurality of pages if, for each page of the plurality of pages, the rendering time is equal to or greater than a processing time threshold. The method also includes removing the page from the rendered plurality of pages if, for each page of the plurality of pages, the rendering time is less than the processing time threshold. The method also includes storing the rendered plurality of pages at the storage location. A printing system is disclosed. The printing system includes a printing device having a print engine. The printing device receives a job having a plurality of pages. The printing system also includes a Raster Image Processor (RIP) system for providing rendered pages to the print engine. The printing system also includes a memory for storing the rendered pages from the RIP system. The printing system also includes a hierarchy of storage drives accessible by the RIP system. The RIP system is configured to render at least one page of a first set of pages of the plurality of pages of the job. The RIP system is also configured to store the at least one page of the rendered first set of pages in the memory. The RIP system is also configured to determine that memory is unavailable. The RIP system is also configured to render at least one second page of a second set of pages of the plurality of pages of the job. The RIP system is also configured to store the at least one page of the rendered second set of pages in a first storage drive in the hierarchy of storage drives accessible by the RIP system. Effect of the Invention

[0009] Advantageous Effects of Invention The present invention provides a method for managing print operations that allows for efficient, reliable and effective printing of pages at a RIP. [Brief description of the drawings]

[0010] Various other features and attendant advantages of the present invention will become better understood when considered in conjunction with the accompanying drawings. [Figure 1] FIG. 1 illustrates a printing system for managing jobs according to disclosed embodiments. [Diagram 2] FIG. 1 is a block diagram illustrating components of a printing device for use in a printing system according to disclosed embodiments. [Diagram 3]FIG. 2 is a block diagram of a RIP system used in processing jobs in a printing system according to a disclosed embodiment. [Figure 4] FIG. 2 is a block diagram of an exemplary RIP for use within a RIP system according to a disclosed embodiment. [Diagram 5] FIG. 1 is a block diagram of a RIP I / O system for use in managing print operations in accordance with disclosed embodiments. [Figure 6] FIG. 1 is a flow diagram for processing a print job using multiple storage according to a disclosed embodiment. [Figure 7] FIG. 4 is a flow diagram for managing print operations of a process and hold print job according to disclosed embodiments. [Figure 8] FIG. 2 is a flow diagram for managing printing operations of a proof and hold job according to a disclosed embodiment. [Figure 9] FIG. 13 is a flow diagram for managing print operations for a collated copy job according to a disclosed embodiment. [Figure 10] FIG. 11 is a flow diagram for reconfiguring storage locations when interrupting a print job in accordance with a disclosed embodiment. [Figure 11] FIG. 1 is a flow diagram for page complexity detection in a RIP system for managing print operations according to a disclosed embodiment. [Figure 12] FIG. 13 is a flow diagram for determining page complexity according to a disclosed embodiment. [Figure 13] FIG. 2 is a block diagram of components used to determine page complexity according to a disclosed embodiment. [Figure 14] FIG. 1 is a flow diagram for managing print operations using page rendering times according to disclosed embodiments. [Figure 15] FIG. 2 is a block diagram of an exemplary process for rendering a print job to multiple storage locations for printing operations according to disclosed embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Specific embodiments of the present invention will now be described in detail. Examples of these embodiments are illustrated in the accompanying drawings. Numerous specific details are set forth in order to provide a thorough understanding of the present invention. While the embodiments will be described in conjunction with the drawings, it will be understood that the following description is not intended to limit the invention to any single embodiment. On the contrary, the following description is intended to cover alternatives, modifications, and equivalents that may be included within the spirit and scope of the appended claims.

[0012] A print job is made up of a variety of pages. Some pages are simple and are rendered quickly relative to engine speed. Other pages may be complex and take longer to render. Additionally, the type of job submitted for processing may vary from job to job. Some jobs require immediate printing, while others are only rendered and printed at a later date, known as process and hold. Other jobs may print only one copy and print the remaining copies upon user request, or may be proof and hold jobs. Other jobs may require multiple copies to be printed. Depending on the type of job and the complexity of the pages within the job, managing the printing operation can result in time and storage / space complexity.

[0013] The disclosed embodiments provide a RIP system that uses hybrid I / O where some pages are rendered in memory and other pages are rendered to disk storage. In the following, simply referring to "disk storage" may refer to a mass storage drive in a hierarchy of storage drives, which may be implemented according to several embodiments. In one embodiment, job pages are processed serially. Pages are rendered in an assigned portion of the host's memory or in the memory of the RIP system or controller of the host printing device.

[0014] Rendered pages accumulate in host memory as they are rendered. Pages are deleted when they are sent to the printing device. In the absence of additional memory, the disclosed embodiments store rendered pages in disk storage. As pages are printed and space becomes available, the disclosed embodiments automatically revert to storing pages in memory. The disclosed embodiments alternate between rendering in memory and rendering in disk storage based on the available space.

[0015] In addition to the above, the disclosed embodiments may target storage of rendered content to a Solid State Drive (SSD) or Hard Disk Drive (HDD) Location for selected job operations. Specifically, jobs accepted as "Process & Hold" or "Proof & Hold" may be rendered to disk storage. This function is performed when the job does not need to be sent for printing immediately. Storing the job on high capacity but slow disk storage allows the fastest data storage for rendering to be available for other jobs that may be printed before the processed or proofed job is released to the printing device.

[0016] Additionally, the disclosed embodiments may leverage page processing prediction capabilities to select where to render a job. Specifically, the disclosed embodiments may render simple pages to memory and complex pages to disk or a mass storage drive. Because only simple pages are rendered to memory, the disclosed embodiments do not need to switch back and forth between memory and disk when memory is exhausted. Instead, the disclosed embodiments may pause rendering since there is no advantage to rendering simple pages ahead of the printing device. Alternatively, the disclosed embodiments may store rendered data from complex pages to disk.

[0017] Simple pages can be discarded after the print operation is completed, while complex pages can be kept. This feature improves reprint performance because the controller or Digital Front End (DFE) needs to render only those pages that can be rendered at the speed of the print engine. This operation can be performed not only for normal print operations, but also for proof and hold jobs and process and hold jobs, which will be described later.

[0018] Optionally, the disclosed embodiments can use the actual rendering time of a page to determine which document pages to retain after a job has been processed or printed. The details of how this works depend on how the RIP system is operating. If the RIP system is saving rendered data to disk for a job operation, the disclosed embodiments can choose to discard the rendered data for pages that were processed faster than the requested engine speed, since this data may be regenerated without affecting production.

[0019] If the RIP system alternates between memory and disk locations, the disclosed embodiments may choose to do the same with the additional operation of moving complex pages from memory to disk to preserve the rendering data for these pages. If a page processing prediction function is used to determine the destination of the rendered data, the disclosed embodiments may still validate the prediction against the actual time it took to process the job. Rendering data for jobs incorrectly classified as simple may be moved from memory to disk storage.

[0020] The disclosed embodiments can also improve performance of collation jobs. Specifically, the disclosed embodiments can discard the rendered data of all simple pages while retaining the data of complex pages. This feature allows the controller or DFE to minimize I / O buffer activity while ensuring that jobs are always processed at engine speeds, once the first copy is printed, as the controller or DFE only renders the simple pages after the first copy is printed.

[0021] Thus, the disclosed embodiments address both performance and storage efficiency during the processing of a job. One feature of the disclosed embodiments is to keep the print engine occupied and running so that engine speeds can be achieved for all pages in a job. Another feature is to manage data storage of rendered pages so that complex pages are available to the print engine when needed.

[0022] The disclosed embodiments manage various storage areas in the system, such as memory and mass storage drives, such as solid state drives and hard disk drives, for rendering pages. A hierarchy of storage areas is maintained based on storage I / O efficiency, storage size, and job type. Rendering of a job starts in one storage area and automatically switches to another storage area in response to system events. This functionality includes ensuring that all components of the system are aware of where the rendering pages reside.

[0023] According to the disclosed embodiment, the front end of the RIP system determines the initial starting storage area, storage tier, from which storage will begin and communicates this information to the renderer. The tier of storage drives determines the storage that the renderer will use when this starting storage runs out of space. For example, if a page is rendered in memory and there is no free space, the tier of storage drives is analyzed. If the tiers are specified in this order as memory, SSD, HDD, the renderer will start rendering the page to the SSD when memory runs out of free space. After rendering the page to the next storage in the tier, if there is free space in the starting storage, the renderer will return to the starting storage to render the next page.

[0024] A page can be written to any storage. For this, the renderer informs the front-end which storage location the page is to be rendered to. The front-end informs the engine manager of the storage location, which reads the page from that location and sends it to the print engine for printing. Once the page is printed, it is deleted from its respective storage location. This function frees up space in the storage area so that the renderer can write more pages. If the renderer does not have enough free space to accommodate more rendered pages in all the storages specified in the hierarchy of storage drives, it will keep waiting for enough free space to become available.

[0025] In the production print market, a long job is one that will print for days. Such jobs are not uncommon. To occupy the engine and keep it running without delay, the print system requires that complex pages be rendered ahead of time to prevent them from becoming a bottleneck and stalling the engine or complicating processing timing times. Simple pages may be rendered at a much faster pace than the engine can print them, which can cause limited storage to fill up faster with pages and create storage space complications. To solve both the time and space complications, rendering must be done using a layered approach to occupying the renderer and using storage.

[0026] For a print job, pages are rendered and then deleted immediately after printing. These pages are kept for a finite amount of time. As a result, the front end of the RIP system sets up a starting location where rendered pages are stored: memory, and a storage hierarchy like memory, SSD, and HDD, where the I / O is fast. The renderer first tries to write rendered pages to memory. If memory is full, the renderer tries to write rendered pages to the SSD, and finally to the HDD.

[0027] A "Process and Hold" job is a type of job that is only rendered and not printed. These pages of this job are printed upon user request. This feature ensures that the engine is not stalled on rendering complex pages when the pages are actually printed. Since the time frame in which these rendered pages are printed is not finite, these pages may not be held in a limited amount of memory. As a result, the front end decides to render the pages of process and hold jobs to a larger storage location, such as an SSD or HDD storage location. The front end sets the starting storage to SSD and the storage hierarchy to SSD, then HDD. The renderer first tries to write the rendered pages to the SSD. If there is no free space on the SSD, it writes the pages to the HDD.

[0028] A "Proof and Hold" job is a type of job where the job is rendered but only one copy of the job is printed. The remaining copies of the job are printed upon user request. This feature is used to proof the printed copy. If the print result is satisfactory, the remaining copies are printed. Since the time frame in which the final copy of the job is printed is not finite, these pages cannot be held in a limited amount of memory. As a result, the front end of the RIP system decides to render the pages of the proof and hold jobs to a larger storage area, such as an SSD or HDD storage location. The front end sets the starting storage to SSD and the storage hierarchy to SSD, then HDD. The renderer first tries to write the rendered pages to the SSD. If there is no free space on the SSD, it writes the pages to the HDD.

[0029] A collated copy print operation requires that the pages of a job are rendered once and then printed multiple times. Rendered pages of a job can only be deleted after the last copy of the page is printed. Because pages cannot be deleted immediately after the first copy is printed, they occupy storage space until the last copy is printed. Because all rendered pages of a job are in storage space, they cannot be held in a limited amount of memory. As a result, the front end of the RIP system determines that the pages of a collated copy job should be rendered to a location on the SSD or HDD, which are larger storage areas. The front end sets the starting storage to SSD and the storage hierarchy to SSD, then HDD. The renderer first tries to write rendered pages to the SSD. If there is no free space on the SSD, it writes the pages to the HDD.

[0030] A print job rendered in memory can be interrupted by an operator and resumed at a later time. It is unknown when the job will be resumed. The front-end RIP system stops sending further pages for rendering when the job is suspended and also informs the engine manager to stop printing pages. Since the duration of the job suspension is unknown, already rendered pages cannot be kept in memory due to limited free space. The disclosed embodiment moves rendered pages from memory to mass storage drives as dictated by the storage hierarchy. The front-end RIP system can also decide to delete simple pages when the job is suspended and re-render the deleted pages when the job is resumed.

[0031] 1 illustrates a printing system 100 for managing jobs using a RIP system 110 according to a disclosed embodiment. The printing system 100 may be located in a print shop or other environment suitable for production printing operations. The printing system 100 includes one or more printing devices 104 that receive jobs 103 from one or more client devices 102.

[0032] Printing device 104 receives jobs, such as job 103, via printing system 100. In some embodiments, job 103 is a print job. After processing job 103, printing device 104 can print or create document 112 on the paper or medium specified by the print job. Printing device 104 is disclosed in further detail in FIG. 2. Printing device 104 also includes controller 106, which is a controller or digital front end (DFE), that facilitates processing of job 103. Controller 106 also includes a RIP system 110, which is disclosed in further detail below.

[0033] For example, the controller 106 may use the RIP system 110 to convert bitmap images, vector graphics, fonts, etc. associated with a page in the job 103 into a bitmapped / rasterized representation of the page, such as C, M, Y, K pixels. The sum of the values ​​of pixels of a particular color in a rasterized page may be proportional to the amount of consumables used by the printing device 104 to print that color. The RIP system 110 may rasterize the pages of the job 103 according to various image rasterization settings. For example, parameters of these image rasterization settings may include calibration curves, paper definitions, ICC profiles, spot color definitions, TRCs, color conversion settings, ink or toner color saturation, rendering intents, K preservation, CGR levels, maximum colorant density, print margins, halftones, etc.

[0034] A print engine 260 is also included in the printing device 104. The printing device 104 may represent an industrial printing device capable of printing thousands of pages per hour. The printing device 104 may be ink-based, toner-based, or both. The print engine 260 may include various parameters that may control the operation of the printing device 104. For example, these settings may include print device maintenance settings that control or affect the head cleaning intervals, head clogging prevention intervals, etc. of the printing device 104. The print engine 260 receives raster output from the RIP system 110 of the printing device 104 to print the document 112 based on the job 103.

[0035] The printing system 100 may receive the job 103 and route it directly to the printing device 104. Alternatively, the printing system 100 may route the job 103 to the print management server 108. The print management server 108 may seek to offload processing of the job 103 from the controller 106 of the printing device 104. This functionality may be desirable when the controller 106 does not have the processing power to process the job 103 in a production printing environment. Thus, the print management server 108 may also include a RIP system 110 that can provide raster output 118 directly to the print engine 260 of the printing device 104. These embodiments allow the controller 106 to offload processing to handle other processes. Additionally, updates to the RIP system 110 may occur at the print management server 108 prior to updates to the RIP system 110 of the printing device 104.

[0036] Job 103 is not limited to a print job that produces document 112. In some embodiments, job 103 may be an estimate job or a preview job. RIP system 110 determines what type of job job 103 is and configures itself accordingly. If it is an estimate job, RIP system 110 configures the RIP to process job 103 without affecting the print processing in controller 106. The estimate RIP processes job 103 and provides an ink or toner estimate 114. The estimate 114 can be provided to an operator without running print engine 260.

[0037] For a preview job, the RIP system 110 configures the RIP processing the job 103 to quickly generate a lower resolution output as the preview 116. The preview 116 may be a lower resolution output compared to the document 112 and the estimate 114. The preview 116 is provided to an operator for review. The preview 116 may be provided to a display device 120 for the operator to view and interact with using an interface. The display device 120 may be a device separate from the client device 102 and the printing device 104. In other embodiments, the display device 120 may be incorporated within the client device 102 or the printing device 104.

[0038] As disclosed above, the RIP system 110 may be a smart system that uses page complexity determination to enable optimal processing for processing various jobs 103. Different jobs received at the printing device 104 or print management server 108 may result in different outputs, such as document 112, estimate 114, or preview 116. The RIP instances within the RIP system 110 are configured according to the type of job 103 received.

[0039] 2 illustrates a block diagram of components of printing device 104 in accordance with disclosed embodiments. The architecture illustrated in FIG. 2 may be applied to any multi-function printing or imaging device that performs various functions, such as printing, scanning, storing, copying, etc., within printing system 100. As disclosed above, printing device 104 may receive and send data from client device 102, print management server 108, and other devices within printing system 100, if they are separate devices.

[0040] The printing device 104 includes a computing platform 201 that performs operations to support these functions. The computing platform 201 includes a computer processing unit, a CPU 202, an image forming unit 204, a memory unit 206, and a network communication interface 210. Other components may be included but are not shown for the sake of brevity. The printing device 104 using the computing platform 201 may be configured to perform various operations such as scanning, copying, printing, receiving or sending facsimile, or document processing. As such, the printing device 104 may be a multi-function peripheral (MFP) that includes one or more functions of a printer or scanner, copier, facsimile machine, and printer. To provide these functions, the printing device 104 includes a printer component 220 that performs printing operations, a copy component 222 that performs copying operations, a scanner component 224 that performs scanning operations, and a facsimile component 226 that receives and sends facsimile documents. The CPU 202 can issue instructions to these components to perform desired operations.

[0041] The printing device 104 also includes a finisher 211 and one or more paper cassettes 212. The finisher 211 includes rotatable downstream rollers for moving the paper having the imaged surface to a tray after a desired operation, and the finisher 211 may also perform additional operations such as sorting the finished paper, stapling the paper sheets, bi-folding, creasing, punching, folding, etc.

[0042] The paper cassette 212 supplies paper to the printer component 220, the copy component 222, the scanner component 224, and the facsimile component 226 for forming an imaging surface on the paper. The paper cassette 212 may also be known as a paper tray. The paper cassette 212 may contain paper having various sizes, colors, compositions, etc. The paper or media in the paper cassette 212 may be considered to be "loaded" into the printing device 104. Information for printing these papers is captured in a paper catalog stored in the controller 106. The paper cassette 212 may be removed for refilling as needed. Printed paper from the printer component 220, the copy component 222, the scanner component 224, and the facsimile component 226 is placed into one or more output bins 227. The one or more output bins 227 may have an associated capacity for receiving completed print jobs before they are emptied or printing must be paused. The output bins may include one or more output trays.

[0043] The document feeder tray 230 is a document processor input feeder tray and may include a physical component of the printing device 104 for receiving paper and documents to be processed. A feeder tray may also refer to one or more input trays of the printing device 104. Documents are placed on or in the document feeder tray 230, which moves the documents to other components in the printing device 104. The movement of documents from the document feeder tray 230 may be controlled by instructions entered by a user. For example, originals may be moved to a scanner flatbed for a scanning operation. In this manner, the document feeder tray 230 provides documents to the scanner component 224. As shown in FIG. 2, the document feeder tray 230 may interact with the print engine 260 to perform the desired operations.

[0044] The memory unit 206 includes memory locations 214 for storing instructions 215. The instructions 215 are executable by the CPU 202 or other processors associated with the printing device 104, such as any processor within the printer component 220, copy component 222, scanner component 224, or facsimile component 226. The memory unit 206 may also store information for various programs and applications 115, as well as data specific to the printing device 104. For example, the storage locations 214 may include data for executing an operating system executed by the computing platform 201 to support components within the printing device 104. According to disclosed embodiments, the memory unit 206 may store tokens and codes used in performing deferred operations for the printing device 104.

[0045] The memory unit 206 may be composed of volatile and non-volatile memory. Volatile memory may include Random Access Memory (RAM). Examples of non-volatile memory may include Read-Only Memory (ROM), Flash memory, Electrically Erasable Programmable Read-Only Memory (EEPROM), digital tape, Hard Disk Drive (HDD) or Solid State Drive (SSD). The memory unit 206 may also include any combination of readable or writeable volatile or non-volatile memory along with other possible memory devices.

[0046] Computing platform 201 may host one or more processors, such as CPU 202. These processors may execute instructions 215 stored in one or more storage locations 214. By executing these instructions, the processors cause printing device 104 to perform various operations. The processors may also incorporate special purpose processing units, such as an Application Specific Integrated Circuit (ASIC) or a Field Programmable Gate Array (FPGA). Other processors may be included to perform operations specific to printer component 220, copy component 222, scanner component 224, and facsimile component 226. In other words, a particular processor may cause printing device 104 to function as a printer, copier, scanner, and facsimile device.

[0047] Printing device 104 also includes an operation panel 208 that may be connected to computing platform 201. Operation panel 208 may include a display 216 and an input 217 to facilitate interaction with a user to provide commands to printing device 104. Display 216 may be any electronic video display, such as a Liquid Crystal Display (LCD). Input 217 may include any combination of devices that allow a user to input information into operation panel 208, such as buttons, a touch screen, a keyboard or keypad, switches, dials, etc. Preferably, input 217 includes a touch screen digitizer overlaid on display 216 that is sensitive to touch to receive input from the user. In this manner, the user interacts with display 216. Using these components, code or other information may be entered into printing device 104.

[0048] The display 216 also operates to display the results from the print management server 108. The display 216 can function as a display device 120 for displaying the preview 116 after it is generated by the RIP system 110.

[0049] The printing device 104 also includes a network communication processor 218. The network communication processor 218 may establish network communications using the network communication interface 210, such as a wireless or wired connection with one or more other image forming devices or network services. The CPU 202 may instruct the network communication processor 218 to send or retrieve information over a network using the network communication interface 210. When data is received at the computing platform 201 over the network, the network communication processor 218 decodes and delivers the received packets to the CPU 202. The CPU 202 may act accordingly by generating operations on the printing device 104. The CPU 202 may also retrieve information stored in the memory unit 206, such as settings of the printing device 104.

[0050] Printing device 104 also includes print engine 260, as disclosed above. Print engine 260 can be a combination of hardware, firmware, or software components operating accordingly to accomplish a task. For example, print engine 260 is comprised of components and software for printing a document. They may receive instructions from computing platform 201 after user input via operation panel 208. Alternatively, print engine 260 may receive instructions from other connected or linked devices.

[0051] The print engine 260 manages and operates the low level mechanisms of the printing device engine, such as the hardware components that actuate the placement of ink or toner on the paper. The print engine 260 may manage and coordinate half-toners, toner cartridges, rollers, schedulers, storage, input / output operations, etc. The RIP system 110, which interprets the Page Description Language (PDL), will send instructions to the lower level print engine 260 for the actual rendering of the image and the application of ink to the paper during operation on the printing device 104. The RIP system 110 may be located in the DFE 106, as disclosed above. Alternatively, the RIP system 110 may be located in the print management server 108 and communicate directly with the print engine 260.

[0052] The printing device 104 may include one or more sensors 262 that collect data and information to provide to the computing platform 201 or the CPU 202. Each sensor 262 may be used to monitor a particular operating condition of the printing device 104. The sensors 262 may be used to indicate the location of a paper jam, a hardware or software component failure, a broken part, an operating system problem, a mis-feed of a document, a toner level, and other operating conditions. The sensors 262 may also detect the number of pages printed or processed by the printing device 104. When the sensor 262 detects an operational problem or fault event, it may send a signal to the CPU 202. The CPU 202 may generate an error alert related to the problem. The error alert may include an error code.

[0053] Some errors may have hardware-related causes. For example, if a fault such as a paper jam occurs in the finisher 211, the display 216 may display information about the error, the location of the fault, or the finisher. In the example where a paper jam occurs in the paper cassettes 212, the display 216 may display information about the jam error as located in one of the paper cassettes.

[0054] Some errors may have firmware-related types of causes, for example, the network communication processor 218 may cause a firmware error or a software error, and the display unit 216 may display firmware-related errors, corresponding error codes, and provide recommendations for addressing the errors, such as rebooting the device.

[0055] The memory unit 206 can store a history of fault events and errors that have occurred along with a timestamp for each error. The printing device 104 communicates with other devices in the printing system 100 via the network communication interface 210 by utilizing network protocols such as those listed above. In some embodiments, the printing device 104 communicates with other devices in the printing system 100 via a REST API, which allows a server to collect data from multiple devices in the printing system 100. REST API and SOAP are application protocols used to transmit data in different formats, such as files, XML messages, JSON messages, etc. By utilizing the applicable network communication protocol and application protocol, the printing device 104, like other printing devices in the printing system 100, transmits and receives data from the client device 102 and the print management server 108.

[0056] 3 illustrates a block diagram of a RIP system 110 for use in processing a job 103 in a printing system 100 according to a disclosed embodiment. As disclosed above, the RIP system 110 may be located in the controller 106 of the printing device 104, or in the print management server 108 in direct communication with the print engine 260 of the printing device 104.

[0057] The RIP system 110 includes a front end 302 and a RIP instance of RIP(1) 3081, a RIP instance of RIP(2) 3082, and a RIP instance of RIP(n) 308n. A RIP instance may be a RIP configured by the front end 302 to process a job 103. A RIP instance may be a standard RIP, a high performance RIP, a very high performance RIP, a preview RIP, a quote RIP, or a failover RIP. All the RIP instances and the front end 302 run in parallel with each other.

[0058] The front end 302 performs various operations. The front end 302 may include multiple sub-units operating in parallel to perform various operations such as spooling a job 103, managing a job 103, managing pages or segments of a job 103, managing RIP instances 3081, 3082, 308n, managing drives, determining a PDL type of a job 103, distributing pages of a segment of a job 103 to RIP instances, serializing pages or segments of a job 103, sending notifications within a printing device 104 or print management server 108, etc.

[0059] The front end 302 can receive a job 103 via the printing system 100. The job 103 may be received from a client device 102 via Internet Protocol within the printing system 100. The job 103 may be spooled by the front end 302 and stored in a spool drive 304. The spool drive 304 may be a configurable drive. The front end 302 determines the PDL type of the job 103. Then, the front end 302 creates a cross reference table 305 in the spool drive 304 and creates RIP instances 3081, 3082, 308n that function as shared memory with the RIPs. The front end 302 may also create print ticket information in the spool drive 304.

[0060] The front end 302 analyzes the job 103 to determine what type of job it is. The front end 302 uses this information to determine the number and type of RIPs to use when processing the job 103. These functions are disclosed in more detail below. Depending on the type of job, the front end 302 configures RIP instances 3081, 3082, 308n. Configuration changes can result in RIPs with a predetermined number of renderers. For example, the RIP instance 3081 can be a standard RIP with a normal number of renderers, such as four. The RIP instance 3082 can be a high performance RIP with a higher number of renderers, such as six. The front end 302 configures the RIP instances depending on the type of job to be processed.

[0061] The front end 302 then distributes pages or segments of the job 103 to the RIP instances 3081, 3082, 308n. The job 103 may be a print job that is divided into segments or pages for parallel processing. The RIP instance 3082 is a high performance RIP and is therefore capable of receiving a particular page or segment of the job 103. A page may refer to one or more pages of the job 103. A segment of the job 103 may also refer to several pages or blocks of data within the job 103. The pages or segments are distributed by the front end 302 using inter-process communication.

[0062] The RIP instances 3081, 3082, 308n can read the cross-reference table 305 along with the print ticket information and the spooled data of the job 103. Each RIP instance then processes the page or segment indicated by the front end 302. The RIP instance can check the cross-reference table 305 to obtain any indications in the print ticket information and the page or segment data in the spool drive 304. The RIP instances 3081, 3082, 308n can then parse the page or segment data to create metadata from the drawing commands.

[0063] The RIP instance renders the metadata to storage 306. Storage 306 may store rendered pages for a print job of job 103. The rendered pages may be stored according to a particular image format, such as Kyocera® Image Format (KIF). The stored pages may then be provided to print engine 260 for printing document 112. For jobs 103 that do not require rendered pages, such as previews or quotes, the data generated by the RIP instance may be provided to front end 302 for further manipulation.

[0064] The RIP system 110 offers advantages over conventional RIP systems: the front end 302 can control the number of renderers per RIP, which speeds up processing of pages or segments. Also, faster processing consumes more memory, so the amount of memory allocated to the RIP can be increased. For slower processing, such as estimate 114 and preview 116, the configured RIP should consume less memory. The front end 302 manages these demands through dynamic configuration of RIPs based on job 103 parameters.

[0065] In some cases, the front end 302 may determine that a job 103 cannot be divided into pages or segments for parallel processing. Thus, a RIP instance, such as RIP instance 308n, may be configured to be an ultra-high performance RIP. An ultra-high performance RIP uses more renderers than a high performance RIP. For example, RIP instance 308n may be configured to use eight renderers. This feature increases the processing speed of RIP instance 308n. The front end 302 may still use RIP instance 3081 and RIP instance 3082 for parallel processing of one job 103 while using RIP instance 308n for processing another job 103 that cannot be divided into pages or segments.

[0066] RIP system 110 provides the capabilities available through parallel processing using dynamically configured RIP instances. RIP system 110 can configure a high performance RIP to improve first page-out time. RIP system 110 may also use different configured RIPs for different purposes, such as preview RIPs, quote RIPs, and failover RIPs. RIP system 110 may also configure an ultra high performance RIP for jobs that cannot be processed in a page or segment parallel manner.

[0067] RIP system 110 also provides the ability to change the number of renderers per RIP. RIP system 110 also changes the number of RIP instances based on the workload, including shutting down certain types of RIPs to start other types of RIPs. RIP system 110 also processes different types of jobs with differently configured RIPs. RIP system 110 also uses differently configured RIPs for different purposes. RIP system 110 configures RIP instances with different image processing pipelines. RIP system 110 also retries failed jobs or job pages in differently configured RIP instances.

[0068] FIG. 4 shows a block diagram of an exemplary RIP 400 used in the RIP system 110 according to the disclosed embodiments. The RIP 400 may represent an arrangement of RIP instances 3081, 3082, 308n. The RIP 400 may represent a hardware and software arrangement used to determine what value each pixel or spot of the output should have, driven by commands from a page description language (PDL). The computer generated output may consist of very small spots. The RIP 400 converts a vector image, which may be a stored image, into a set of mathematical equations describing the lines and curves, and the pattern of spots required to generate the output, which may be a raster image. The interpreter 402 converts the job file into a display list, which the renderer 418 converts into a bitmap output that describes the pages of the document.

[0069] The RIP 400 converts text and image data from different file formats, including PDF, TIFF, or JPEG, into a format that the printing device 104 can understand. The process of raster image processing a page implements several steps that are performed regardless of whether the page is acquired as PostScript, PDF, or another page description language (PDL). In summary, the RIP 400 can provide interpretation, rasterization, and screening.

[0070] Segment 401 may be a job file associated with job 103. Segment 401 may be provided to RIP 400 for conversion of its code to raster or bitmap code. As disclosed above, front end 302 receives job 103. Front end 302 may divide job 103 into segments for parallel processing by RIP instances. Preferably, segment 401 is a page of a document of job 103. The RIP processes the pages in parallel within RIP system 110. RIP 400 is one of the RIP instances. In other embodiments, segment 401 may be multiple pages, graphic designs, or other portions of job 103.

[0071] Segment 401 is received by an interpreter 402, which interprets the commands in the code to redraw the objects and page elements as vector objects 404, raster objects 406, and text objects 408. The interpreter 402 parses the specific PDL into drawing commands. The PDL of segment 401 is read and decoded into graphic elements that are placed on the sheet. Each element can be an image, a text character, a fill, a stroke, etc., or it can be listed in a vector object 404, raster object 406, or text object 408.

[0072] The rendering unit 409 receives vector objects 404, raster objects 406, and text objects 408 and converts them into metadata that can be provided to a renderer 418. Thus, the rendering unit 409 converts vector objects 404 to rendering services 410, raster objects 406 to graphic services 412, and text objects to font rasterizer 414.

[0073] The RIP 400 may also implement a color converter 416. The color converter 416 may implement color conversion operations on the metadata generated by the rendering unit 409. The color converter 416 provides color management and calibration. These operations may be applied during interpretation or during rendering, depending on the settings and job content. Color print resources may be accessed to provide color management.

[0074] The renderer 418 processes the metadata from the drawing unit 409 and converts all the graphic elements into the appropriate pattern of pixels to form the output raster. As the drawing service 410, the resolution independent vector objects 404 are converted into pixels. Screening takes the raster image of the pixels and creates cyan, magenta, yellow, and black separations (bands) that are individually screened (dithered). These are halftone dots in the form of a bitmap output 420 that consists of commands that the print engine 260 can understand.

[0075] The disclosed embodiments may also determine a dot count value 422 from the rendered image provided by the renderer 418. The dot count value may be adjusted based on screening and based on settings on the printing device 104. The dot count value 422 may be reported to determine a quote job estimate 114, as disclosed below.

[0076] The rendered bitmap output 420 may be stored in the storage 306 for delivery to the print engine 260 when all pages or segments of the job 103 have been processed. The RIP 400 exhibits one pass for rendering and providing output. Preferably, the RIP 400 exhibits multiple rendering passes using multiple renderers. In the disclosed embodiment, a renderer 418 may be used for each channel of the RIP 400, such as one each for cyan, magenta, yellow, and black. The number of renderers 418 may be configured by the front end 302 depending on the job 103. Each renderer 418 requires memory and processing resources. A larger number of renderers 418 in the RIP 400 consumes more memory but runs faster. A smaller number of renderers 418 in the RIP 400 consumes less memory but runs slower.

[0077] 5 illustrates a block diagram of an I / O system 500 for a RIP for use in managing print operations according to disclosed embodiments. The I / O system 500 may be part of or include components of the RIP system 110. In some embodiments, the I / O system 500 works in conjunction with the RIP system 110 for print operations. For example, the I / O system 500 may include the front end 302 and the renderer 418 disclosed above. Additionally, the I / O system 500 may include a new component within the RIP system 110, namely, the engine manager 512, which is disclosed in more detail below.

[0078] The front end 302 determines a hierarchy 502 of storage drives. The hierarchy 502 may include a starting storage area and a storage hierarchy to be applied during a print operation. The front end 302 may provide the hierarchy 502 to a renderer 418 of a RIP 400 in the RIP system 110. The RIP 400 is disclosed above. The front end 302 may also enable an operation 504 in which the hierarchy 502 determines a storage location for a rendered page. The renderer 418 executes the operation 504 and stores data for the rendered page in a memory 506, a solid state drive SSD 508, or a hard disk drive HDD 510. The memory 506 may correspond to the storage 306 disclosed in FIG. 3. Alternatively, the storage 306 may refer to all storage accessible by the RIP system 110 and the renderer 418.

[0079] The renderer 418 consults the hierarchy 502 for where and how to store the rendered pages. For example, the starting storage may be memory 506, as specified by the hierarchy 502. The hierarchy 502 also dictates what storage the renderer 418 will use if the starting storage, i.e., memory 506, becomes unavailable. The memory 506 may be unavailable because there is no free storage space left to receive new data or the memory is offline for some reason. In this case, the rendered pages from the renderer 418 must be stored elsewhere.

[0080] For example, if a page is rendered in memory 506 and the storage location runs out of space, the hierarchy of storage devices 502 is analyzed, preferably by the renderer 418. Alternatively, the renderer 418 may determine that the memory 506 is out of space and ask the front end 302 what to do. The hierarchy 502 may have, in a specified order, memory 506, SSD 508, and HDD 510. Memory 506 is the starting storage, SSD 508 is used when memory 506 becomes unavailable, and HDD 510 is used when SSD 508 becomes unavailable.

[0081] In some embodiments, the SSD 508 may have a larger storage capacity than the memory 506. The SSD 508 may be a solid state drive with semiconductor-based storage that may use NAND flash memory to store persistent data. The HDD 510 may be a non-volatile storage drive to retain stored states even when the device is not powered. The HDD 510 may also have a larger storage capacity than the memory 506 and the SSD 508. The SSD 508 and the HDD 510 are both storage devices, but they operate differently. The SSD 508 is quieter, consumes less energy, and is faster than the HDD 510, but is also more expensive. The HDD 510 may be cheaper and offer more storage capacity. The SSD 508 may store data on memory chips that are instantly accessible, while the HDD 510 is a traditional storage device that uses a disk to read and write data.

[0082] While memory 506 is internal to the system, SSD 508 and HDD 510 may be external storage accessible by RIP system 110. When memory 506 becomes unavailable, such as by filling up with data for rendered pages that have not yet been printed, renderer 418 moves to the next storage device defined by hierarchy 502. Here, SSD 508 is the next device according to hierarchy 502. After rendering a page to SSD 508, renderer 418 returns to the starting storage or memory 506 to render the next page, if free space or memory 506 is available. Pages may have been sent to print engine 260 by engine manager 512 and therefore deleted from memory 506. When free space becomes available in memory 506, renderer 418 can resume storing rendered pages.

[0083] In some embodiments, such as for large print jobs, the SSD 508 may also become unavailable, running out of space or going offline for some reason. In such a case, the renderer 418 may analyze the hierarchy 502 and determine that the default storage after the memory 506 and the SSD 508 is the HDD 510. The next rendered page is stored on the HDD 510. As disclosed above, the front end 302 may perform a storage operation to indicate that free space is available in the memory 506 or the SSD 508 and to return thereto. Because the rendered page may be written to any storage, the renderer 418 informs the front end 302 in which storage location the page will be stored.

[0084] The front end 302 informs the engine manager 512 on which storage the rendered page is stored. The front end 302 can inform the engine manager 512 of the storage location of the rendered page, which can be either the memory 506, the SSD 508, or the HDD 510. The engine manager 512 reads the rendered page from that location and provides it to the print engine 260 for printing. After the page is printed, in some embodiments, the page is deleted from its respective storage location to make room for the renderer 418 to write more pages to storage. If all storage locations specified by the hierarchy 502 are unavailable because they do not have enough space or are offline, the renderer 418 continues to wait for free space to become available in the memory 506, the SSD 508, and the HDD 510.

[0085] Referring to the engine manager 512, the front end 302 can perform an operation 511 to instruct the engine manager 512 to retrieve pages of the print job 103 in order. The order can refer to different storage locations: memory 506, SSD 508, and HDD 510. For example, the print job 103 may include ten pages, pages (1)-(10). Pages (1)-(3) are rendered by the RIP 400 and stored in the memory 506. Since there is not enough storage in the memory 506 to store any more pages, the renderer 418 checks the tier 502 to determine where the next page should be stored. The tier 502 indicates that the SSD 508 is the next storage in the tier. The renderer 418 stores the rendered page (4) in the SSD 508 and then checks whether the memory 506 has free space.

[0086] Pages (4)-(6) are rendered in the RIP 400. The rendered pages (4)-(6) are stored in the SSD 508 and the front end 302 is updated with their location. Using the same example, since there is no free space in the SSD 508, the renderer 418 again refers to the hierarchy 502. The hierarchy 502 indicates that if the memory 506 and the SSD 508 are not available, the HDD 510 is where the renderer 418 will store the rendered pages, according to operation 511. The renderer 418 realizes that there is free space available in the memory 506, but at that point it can store the rendered pages (7) and (8) on the HDD 510. The renderer 418 goes back to the memory 506 and stores the rendered pages (9) and (10) there.

[0087] The front end 302 is informed of different storage locations for the document containing pages (1)-(10): Pages (1) to (3) Memory 506 Pages (4) ~ (6) SDD508 Pages (7) to (8) HDD510 Pages (9)-(10) Memory 506

[0088] These locations are provided from the renderer 418 to the front end 302. The front end 302 provides these locations to the engine manager 512. The engine manager 512 reads the different storage locations according to operation 511, retrieves the entire document, and provides it to the print engine 260 for printing. The engine manager 512 may be an interface between the RIP system 110 and the print engine 260. The engine manager 512 retrieves pages (1)-(3) from the memory 506, and then retrieves pages (4)-(6) from the SSD 508. Pages (7) and (8) are retrieved from the HDD 510. Pages (9) and (10) are retrieved from the memory 506. Pages (1)-(10) are printed in the order they were retrieved from their respective storage locations and provided to the print engine 260.

[0089] Other features and variations can be implemented within the embodiments disclosed below. In some cases, rendered pages may be written to the SSD 508 or HDD 510, depending on the type of print job, without the need to determine if the memory 506 is full.

[0090] 6 illustrates a flow diagram 600 for processing a print job using multiple storage locations 602 in accordance with disclosed embodiments. The multiple storage locations 602 include memory 506, SSD 508, and HDD 510. As disclosed above, the renderer 418 can place and store rendered pages in locations within memory 506, SSD 508, and HDD 510 depending on available storage and tier 502. FIG. 6 illustrates an example of a rendering operation in accordance with disclosed embodiments.

[0091] In production printing, some print jobs may be long print jobs that print on the printing device for hours or even days. To keep the print engine 260 occupied and printing without delay, the disclosed embodiments may require pages to be rendered in advance to prevent complex pages from becoming a bottleneck and stalling the print engine 260. In the present embodiment, this is referred to as time complexity. Complex pages are disclosed in more detail below. In this example, a complex page may be a page in a document that is rendered slower than the engine speed of the print engine 260. The engine speed refers to the print speed of the print engine 260 after receiving the rendered page from the engine manager 512.

[0092] A non-complex page may be referred to as a simple page. Rendering of a simple page may occur at a pace faster than the engine speed of the print engine 260. A rendered simple page may fill up the limited storage space of the memory 506. In the present embodiment, this is referred to as spatial complexity. To address both time and space complexity, the renderer 418 must use a layered approach to store the rendered pages in multiple storage locations 602 to populate and render.

[0093] For print job 103, pages of the print job are rendered and printed and then immediately deleted. These pages are kept for a finite amount of time. As a result, front end 302 sets the starting location of rendered pages from renderer 418 to the storage location with the fastest I / O, namely memory 506. Hierarchy 502 sets the storage location order as disclosed above to memory 506, SSD 508, and HDD 510. Renderer 418 first tries to write rendered pages of print job 103 to memory 506. If memory 506 is not available, the rendered pages are stored in SDD 508. If SDD 508 is not available, the rendered pages are stored in HDD 510.

[0094] A print job 103 is received by the front end 302. The print job 103 may include multiple pages. These pages may be processed sequentially by the front end 302. Step 604 is performed by determining whether the page has already been rendered, perhaps during a previous iteration of the printing process. If not, the page needs to be rendered by the renderer 418. Additionally, the front end 302 may provide a hierarchy 502 to the renderer 418. The hierarchy 502 may include a starting storage in memory 506 and a hierarchy of multiple storage locations 602.

[0095] Renderer 418 renders the page into a rendered page of data suitable for use by print engine 260. RIP operations are disclosed above with respect to RIP 400 and RIP system 110. Step 606 executes by determining whether free space is available in the current storage location of multiple storage locations 602. If no, step 608 executes by proceeding to the next storage in hierarchy 502. Flow diagram 600 returns to renderer 418 which again in step 606 looks at the next storage listed in hierarchy 502 to determine whether free space is available.

[0096] If step 606 is Yes, step 610 executes by writing or storing the rendered page in storage as indicated by the renderer 418. The page store location 612 of the written page is provided to the front end 302. For example, if the page was rendered by the renderer 418, step 606 determines whether free space is available in the currently used storage location. In this example, the storage location is memory 506. If memory 506 is not available, step 608 executes by moving to the next storage location in the hierarchy 502, which is the SSD 508. The renderer 418 then determines that the SDD 508 is available so that step 610 writes the page to the SSD 508. The page store location 612 indicates the SSD 508 as a location to the front end 302.

[0097] If step 604 is Yes, the page that the front end 302 is considering has already been rendered. Perhaps the page was previously rendered using the process disclosed below. In step 606, the front end 302 has a location where the rendered page is stored based on the page store 612. The page store 614 of the rendered page is provided to the engine manager 512. The engine manager 512 performs step 616 by reading the stored page from its store. Using the above example, the engine manager 512 reads the page from the SSD 508.

[0098] The engine manager 512 provides the retrieved pages to the print engine 260 for printing. Step 618 executes by indicating that the pages have been printed. The engine manager 512 is notified by the print engine 260 that printing is complete. Step 620 executes by deleting the printed pages from the appropriate storage location. Using the example above, the printed pages would be deleted from the SSD 508.

[0099] The multiple storage locations 602 include memory 506, SSD 508, and HDD 510. These storage locations store rendered pages from the renderer 418. These rendered pages are kept in the storage locations until they are printed. The engine manager 512 instructs the storage locations to delete the printed pages. Thus, memory 506 contains rendered pages 630, SSD 508 contains rendered pages 632, and HDD 510 contains rendered pages 634. The disclosed embodiments use available free space among memory 506, SSD 508, and HDD 510 to process and store rendered pages during long print jobs without causing delays or mismatches between engine speed and rendering speed.

[0100] In some embodiments, the flow diagram 600 may have the hierarchy 502 default back to the memory 506 as the starting storage for all pages. Thus, at least initially, free space on the memory 506 is checked to see if the rendering page is stored there first, before proceeding to the SDD 508 or HDD 510. Alternatively, the renderer 418 may retain the current storage location for the next page so that the page is kept in order until a change in the storage hierarchy is required.

[0101] 7 illustrates a flow diagram 700 for managing print operations of a print job, a process and hold job 703, according to a disclosed embodiment. The flow diagram 700 may refer to FIGS. 1-6 for illustrative purposes. However, the flow diagram 700 is not limited to the embodiment disclosed by FIGS. 1-6.

[0102] A process and hold job 703 is received at the printing device 104 and provided to the front end 302 of the RIP system 110. The process and hold job 703 may correspond to the print job 103 disclosed above, although the term process and hold is used herein as a description of the type of job. Furthermore, a process and hold job is not a "print job" in the sense that it is received and printed. A process and hold print job is a type of job that is only rendered and may not be printed. Pages are printed at the request of an operator. This feature ensures that rendering of complex pages does not tie up the print engine 260 when the pages are actually printed. Because there is no finite time frame to print a rendered page, the rendered page cannot be held in a limited amount of memory after processing through the RIP system 110.

[0103] As a result of the print job being a process and hold job 703, the front end 302 can direct that these types of jobs be stored in larger storage locations, such as the SSD 508 and HDD 510, when rendered. Thus, the storage location 602 for the process and hold job 703 can include only the SSD 508 and the HDD 510. The front end 302 can provide the hierarchy 502 with the starting storage being the SSD 508 and the storage hierarchy being the SSD 508 followed by the HDD 510. The front end 302 can provide the hierarchy 502 to the renderer 418. According to the hierarchy 502, the renderer 418 will first attempt to write rendered pages of the process and hold job 703 to the SSD 508. If the SSD 508 is not available, the rendered pages are written to the HDD 510.

[0104] Thus, for each page, step 704 is performed by determining whether there is free space on the starting storage, or in this case SSD 508. If there is not, step 706 is performed by moving to the next storage in the hierarchy 502, which in this example is HDD 510. The renderer 418 updates its storage location to HDD 510 and repeats step 704. Additionally, for this page, the renderer 418 provides the page location 708 to the front end 302 indicating that the page, and possibly subsequent pages, will be written to HDD 510.

[0105] If step 704 is Yes, then the page storage location 708 is provided to the front end 302 and step 710 executes by writing the page to the appropriate storage location. If the storage location is the SSD 508, then the page is stored with the rendered pages 632. If the storage location is the HDD 510, then the page is stored with the rendered pages 634. As disclosed above, the renderer 418 starts by writing the rendered page to the rendered pages 632, but switches to the rendered pages 634 if the SSD 508 is unavailable due to limited storage capabilities or some other reason.

[0106] 8 illustrates a flow diagram 800 for managing print operations of a proof and hold job 803 according to a disclosed embodiment. The flow diagram 800 may refer to FIGS. 1-7 for illustrative purposes. However, the flow diagram 800 is not limited to the embodiment disclosed by FIGS. 1-7.

[0107] A proof and hold job 803 is received by the printing device 104 and provided to the front end 302 of the RIP system 110. The proof and hold job 803 may correspond to the print job 103 disclosed above, but the term proof and hold is used here as a description of the type of job. A proof and hold job is a type of job where a job is rendered but only one copy of the job is printed. The printed copy is used to "proof" the job so that changes can be made, if necessary, before the remaining copies are printed. The remaining copies are printed at the request of the operator.

[0108] Because the time frame in which the final copy of the job is printed is not finite, the rendered pages of the proof and hold job 803 may not be retained in the limited amount of storage available in memory 506. As a result, the front end 302 determines that the rendered pages of the proof and hold job should be stored in a larger storage location, such as SSD 508 and HDD 510. The front end 302 sets the starting storage to SSD 508 and the storage tier to SSD 508, HDD 510 in tier 502. Memory 506 is not considered. The renderer 418 will first attempt to write the rendered pages to SSD 508. If SSD 508 is not available, the renderer 418 will write the rendered pages to HDD 510.

[0109] Thus, a proof and hold job 803 is received at the printing device 104 and provided to the RIP system 110 for processing. The front end 302 determines that the received job is a proof and hold type job and instructs the renderer 418 to use the tier 502 with the starting storage being the SSD 508 and the tier being the SSD 508 followed by the HDD 510. The front end 302 may consider each page of the proof and hold job 803. Step 802 is performed by determining whether the page has already been rendered. If no, the page is provided to the RIP 400 with the renderer 418 for processing into a rendered page suitable for a print operation.

[0110] The renderer 418 uses the tier 502 to determine that the starting storage for storing the rendered page is the SSD 508. Thus, step 804 is performed by determining whether the SSD 508 has free space as the storage location specified by the tier 502. The SSD 508 may also be unavailable for other reasons, such as being offline. If step 804 is Yes, step 809 is performed by writing the page to the SSD 508. If step 804 is No, step 806 is performed by moving to the next storage specified in the tier 502. In this example, the next storage is the HDD 510. The renderer 418 adjusts its storage location to the HDD 510 and provides the page storage location 808 for this page to the front end 302.

[0111] Step 804 is repeated to determine if there is free space on the HDD 510. If step 804 is Yes, the renderer 418 performs step 809 by writing the page to the HDD 510. If step 804 is No, the renderer 418 may need to check the SSD 508. If space is not available, the hierarchy 502 can instruct the renderer 418 to query the SSD 508 to see if space is now available. Some pages may have been deleted to free up space.

[0112] Returning to step 802, if the page has already been rendered based on a previous operation, a page store 810 is provided from the front end 302 to the engine manager 512. The engine manager 512 uses the page store 810 to query the appropriate stores 602 for the rendered page. Step 812 is performed by reading the page from the appropriate store in either the SSD 508 or the HDD 510. The engine manager 512 provides the rendered page to the print engine 260. Step 814 is performed by printing the rendered page. In some embodiments, the engine manager 512 can instruct the rendered page to be removed from the rendered pages 632 or the rendered pages 634.

[0113] 9 illustrates a flow diagram 900 for managing print operations for a collated copy job 903, according to a disclosed embodiment. The flow diagram 900 may refer to FIGS. 1-8 for illustrative purposes. However, the flow diagram 900 is not limited by the embodiments disclosed by FIGS. 1-8.

[0114] A collated copy job 903 is received at the printing device 104 and provided to the front end 302 of the RIP system 110. The collated copy job 903 may correspond to the print job 103 disclosed above, but the collated copy term is used here to describe the type of job. A collated copy job requires that pages of the job are rendered once but printed multiple times. In other words, the collated copy job 903 may include multiple copies of a document. Only rendered pages of a collated copy job 903 may be deleted after the last copy of a page is printed.

[0115] Because pages may not be deleted immediately after the first print, the rendered pages occupy storage locations until all pages are printed. Because all rendered pages of a job are in storage, these pages may not be kept in a limited amount of memory. As a result, the front end 302 determines that the pages of the collated copy job 903 should be written to a storage location larger than the memory 506, such as the SSD 508 or the HDD 510. The front end 302 sets the storage tier in the hierarchy 502 as the SSD 508 as the starting storage, and then the HDD 510. The memory 506 is not taken into account. The renderer 418 will first attempt to write the rendered pages to the SSD 508. If the SSD 508 is not available, the renderer 418 will write the rendered pages to the HDD 510.

[0116] Thus, a collated copy job 903 is received at the printing device 104 and provided to the RIP system 110 for processing. The front end 302 determines that the received job is a collated copy type job and instructs the renderer 418 to use the tier 502 with the starting storage being the SSD 508 and the tier being the SSD 508 followed by the HDD 510. The front end 302 may consider each page of the collated copy job 903. Step 902 is performed by determining whether the page has already been rendered. If not, the page is provided to the RIP 400 with the renderer 418 for processing into a rendered page suitable for the printing operation.

[0117] The renderer 418 uses the tier 502 to determine that the starting storage for storing the rendered page is the SSD 508. Thus, step 904 is performed by determining whether the SSD 508 has free space as the storage location specified by the tier 502. The SSD 508 may also be unavailable for other reasons, such as being offline. If step 904 is Yes, step 906 is performed by writing the page to the SSD 508. If step 904 is No, step 908 is performed by moving to the next storage specified in the tier 502. In this example, the next storage is the HDD 510. The renderer 418 adjusts its storage location to the HDD 510 and provides this page storage location 910 to the front end 302.

[0118] Step 904 is repeated to determine whether there is free space on the HDD 510. If step 904 is Yes, the renderer 418 performs step 906 by writing the page to the HDD 510. If step 904 is No, the renderer 418 may need to check the SSD 508. If no free space is available on the HDD 510, the hierarchy 502 can instruct the renderer 418 to query the SSD 508 to see if free space is now available. Some pages may have been deleted to free up space.

[0119] Returning to step 902, if the page has already been rendered based on a previous operation, a page store 912 is provided from the front end 302 to the engine manager 512. The engine manager 512 uses the page store 912 to query the appropriate stores 602 for the rendered page. Step 914 is performed by reading the page from the appropriate store in either the SSD 508 or the HDD 510. The engine manager 512 provides the rendered page to the print engine 260. Step 916 is performed by printing the rendered page. In some embodiments, the engine manager 512 can instruct the rendered page to be removed from the rendered pages 632 or the rendered pages 634.

[0120] Step 918 executes by determining if this page is the last page printed for the last copy printed for the collated copy job 903. For example, the collated copy job 903 may include a thousand copies of a document. A page in a document should be printed a thousand times. Therefore, the page cannot be deleted from the storage location on either the SSD 508 or the HDD 510 until the final copy is printed. Therefore, step 918 determines if this print instance is the last one needed to complete the collated copy job 903. If No, the flow diagram 900 returns to the engine manager 512 to print additional pages. If step 918 is Yes, step 920 executes by deleting the page from the appropriate storage location.

[0121] 10 illustrates a flow diagram 1000 for reconfiguring storage when aborting a print job, according to a disclosed embodiment. The flow diagram 1000 may refer to FIGS. 1-9 for illustrative purposes. However, the flow diagram 1000 is not limited to the embodiment disclosed by FIGS. 1-9.

[0122] A print job, such as a print job 103, a process and hold job 703, a proof and hold job 803, or a collated copy job 903, may be suspended by an operator to be resumed at a later time. For simplicity, the disclosed embodiment will hereinafter refer to a print job 103. The print job 103 may be rendered in memory 506 as part of normal printing operations when a suspend job command 1003 is received at the front end 302.

[0123] As a result of the suspend job instruction 1003, step 1004 is performed by the front end 302 stopping sending further pages to the RIP 400 for rendering and instructing the renderer 418 to stop rendering. Step 1006 is also performed by stopping printing of the print job 103. The front end 302 notifies the engine manager 512 to stop sending pages to the print engine 260. Since the pause duration of the suspended job is unknown, the already rendered pages, i.e., the rendered pages 630, cannot be kept in the memory 506. In the disclosed embodiment, the rendered pages of the print job 103 in the rendered pages 630 are moved from the memory 506 to the storage drive as defined in the hierarchy 502. The front end 302 may also delete simple or non-complex pages when the job is suspended and re-render the deleted pages when the print job resumes printing.

[0124] Thus, step 1008 is performed by deleting the rendered page from rendered pages 630 in memory 506, freeing up this space for other printing operations of printing device 104. Step 1010 is performed by moving the page deleted in step 1008 to either rendered pages 632 on SSD 508 or rendered pages 634 on HDD 510. Hierarchy 502 may specify the storage location to use. For example, hierarchy 502 may define SSD 508 as a destination for moving the deleted page. If SSD 508 is not available, the deleted page may be stored on HDD 510.

[0125] If some of the rendered pages for the interrupted print job 103 are not complex, they may not be stored on the SSD 508 or HDD 510 since they may be rendered when the print operation is resumed without significantly limiting the print engine 260. The determination of complex pages is disclosed in more detail below.

[0126] 11 illustrates a flow diagram 1100 for page complexity detection in a RIP system 110 for managing print operations, according to a disclosed embodiment. The flow diagram 1100 may refer to FIGS. 1-10 for illustrative purposes. However, the flow diagram 1100 is not limited to the embodiment disclosed by FIGS. 1-10.

[0127] Complexity detection according to the disclosed embodiments may be implemented in the RIP system 110. In some embodiments, complexity detection may be implemented in the controller 106. In the RIP system 110, the job 103 is received by the front end 302. If the job 103 needs to undergo page complexity determination processing, the front end 302 sets a complexity flag 1104 for complexity page detection during a page initiation request to a RIP in the RIP system 110. The front end 302 may set the complexity flag 1104 after being notified that a current storage location, such as memory 506, is not available or that free space is not available in the current storage location. Step 1102 is performed by determining that a storage location according to the hierarchy 502 is not available, for example, as disclosed by step 804 of the flow diagram 800.

[0128] A renderer 418 may receive a page 1105 from a job 103. The renderer 418 performs a preflight check of the page 1105 and collects statistics only if the complexity flag 1104 is true. Step 1106 is performed by the renderer 418 detecting the page complexity of the page 1105. The renderer 418 may determine the page complexity of the page 1105 based on a set of weighted formulas and rules. These features are disclosed in further detail below. Using the collected and determined information, the disclosed embodiments determine whether the page 1105 is complex.

[0129] Step 1108 is performed by determining whether the page 1105 is complex. This process is disclosed in more detail below. If step 1108 is Yes, the page 1105 is a complex page. Step 1112 is performed by storing the rendered page 1105 in memory 506 by the associated RIP, as disclosed above. Specifically, the rendered page 1105 may be added to the rendered pages 630 in memory 506 along with a location in storage to obtain the rendered page. In other embodiments, the hierarchy 502 may instruct the renderer 418 to store the rendered page 1105 on the SSD 508 or HDD 510 if the memory 506 is not available. Step 1113 is performed by returning the storage location of the rendered page 1105 to the front end 302.

[0130] If step 1108 is No, then page 1105 is a simple page, i.e., a non-complex page. Step 1114 executes by not rendering and not storing the simple page. The RIP does not render page 1105 and does not store it, for example in memory 506. Simple pages may be rendered when a print operation is initiated without significant impact on print engine 260. These pages do not need to take up free space to store if free space is not readily available.

[0131] FIG. 12 illustrates a flow diagram 1200 for determining page complexity according to a disclosed embodiment. The flow diagram 1200 may refer to FIGS. 1-11 for illustrative purposes. However, the flow diagram 1200 is not limited by the embodiments disclosed by FIGS. 1-11. The flow diagram 1100 may be implemented in the RIP system 110. More specifically, the flow diagram 1100 may be implemented in the interpreter 402 or the renderer 418 of a RIP in the RIP system 110. In other embodiments, the flow diagram 1200 may be implemented elsewhere in the printing system 100, such as in the controller 106.

[0132] A page 1105 is received at a RIP 400 having a renderer 418. The page 1105 may be part of a job 103. According to the disclosed embodiment, it is determined that storage for rendered pages of the job is unavailable or limited and cannot store the entire data set of the rendered page. The disclosed embodiment determines whether the page 1105 is complex. Step 1202 is performed by determining a page processing weight for the page 1105. This process is disclosed in more detail below and is based on a set of rules and a weighted formula. Step 1204 is performed by determining whether the page processing weight is equal to or greater than a base page processing amount. The base page processing weight is disclosed in more detail below and is determined based on the engine speed of the print engine 260. Thus, determining whether a page is complex relates to whether the page can be rendered at a "constant rate" without interruption during a print operation.

[0133] If step 1204 is Yes, then in step 1206 the page 1105 is marked as a complex page. Referring to flow diagram 1100, the page 1105 is stored in a storage location accessible by the RIP system 110. Thus, step 1207 is performed by writing the rendered page 1105 to storage. In some embodiments, the storage location may be memory 506 if there is free space available. If no free space is available, the disclosed embodiments store the rendered page 1105 in SSD 508 or HDD 510 according to hierarchy 502. If step 1204 is No, then the page 1105 is marked as a simple page in step 1208. Step 1210 is performed by not rendering and storing the page 1105 so that the page 1105 may be rendered at a subsequent time.

[0134] 13 shows a block diagram of components used to determine page complexity according to disclosed embodiments. As disclosed above, a base page processing weight 1310 and a page processing weight 1306 are determined for use in determining whether a page 1105 is complex or simple. Both of these values ​​are calculated using information available from the printing device 104 and the objects in the page 1105. These features are disclosed in further detail below.

[0135] Base page processing weight 1310 is related to engine speed 1308 of print engine 260 of printing device 104. Engine speed 1308 may refer to the pages or sheets per minute that print engine 260 can process, i.e., put ink on paper. This speed may refer to the average speed of past print jobs or the speed at which a page without objects is printed, such as a page with only text. The disclosed embodiments may assign a weight or value to engine speed 1308.

[0136] For example, print engine 260 may have an engine speed 1308 of 150 PPM. This value may be based on previous print jobs and their engine speeds for printing pages of those jobs regardless of the content of those pages. Alternatively, the disclosed embodiments may take the engine speed for printing a particular type of page, such as a page with text only, a page with objects, a page with color printing, etc. Using this example, the base page processing weight 1310 for an engine speed 1308 of 150 PPM may be "10.0".

[0137] To determine the page processing weight 1306, a page processing weight determination engine 1304 may be implemented in the renderer 418 of a RIP in the RIP system 110. The page processing weight determination engine 1304 may also be implemented in the controller 106, the print management server 108, or elsewhere in the RIP system 110. The page processing weight determination engine 1304 may take into account page objects 1324 and object processing weights 1326 from the page 1105. These features are disclosed separately below.

[0138] A page object 1324 is an object such as an image, graphic, text, etc., in a page 1105. For example, a page 1105 may include a first page object 1318, a second page object 1320, and a third page object 1322. The third page object 1322 may include a spot color 1323 that is necessary to print the third page object correctly. As disclosed above, the objects may have a type such as vector, text, image, etc. The objects may be further classified into operators such as form, shading, group, type three characters, pattern, font, color space, spot color, etc. For example, the first page object 1318 may be a vector object with shading as an operator, the second page object 1320 may be a text object with a certain font and some type three characters as an operator, and the third page object 1322 may be an image object with spot color 1323 as an operator.

[0139] The disclosed embodiments may compile the page objects and their operators into a page object 1324 for the page 1105. The page object 1324 is provided to a page processing weight determination engine 1304. The page processing weight determination engine 1304 may use one or more weighting formulas to determine the processing weight of the page object 1324. The weighting formulas may depend on the object processing weights 1326 provided from a complexity model 1325. The disclosed embodiments collect statistics and generate the complexity model 1325 based on these determinations. The complexity model 1325 is based on the object types or various components of the page, such as vectors, text, images, etc., as disclosed above. The objects in the complexity model 1325 may also be further categorized into operators.

[0140] When the page processing weight determination engine 1304 receives a page object 1324 of the page 1105, it may obtain the object processing weight from the complexity model 1325. Alternatively, the page object 1324 may be provided to the complexity model 1325, which may provide the page object 1324 along with the object processing weight 1326 to the page processing weight determination engine 1304. The first page object 1318 may be compared to similar page objects in the complexity model 1325 to obtain a processing weight for the first page object. The second page object 1320 may be compared to similar page objects in the complexity model 1325 to obtain a processing weight for the second page object. The third page object 1322 may be compared to similar page objects in the complexity model 1325 to obtain a processing weight for the third page object. In some embodiments, the object processing weights of the first page object 1318, the second page object 1320, and the third page object 1322 may be added together to determine the page processing weight 1306.

[0141] The page complexity determination engine 1302 applies the rule that if the page processing weight 1306 exceeds the base page processing weight 1310, the page is marked as complex. If the page processing weight 1306 exceeds the base page processing weight 1310, the page 1105 is marked as complex. If the page processing weight 1306 is less than or equal to the base page processing weight 1310, the page 1105 is marked as simple. With reference to the embodiments disclosed above, complex pages are stored in a storage location, while simple pages may be discarded.

[0142] 14 illustrates a flow diagram 1400 for managing print operations using rendering time of a page 1105, according to a disclosed embodiment. The flow diagram 1400 may refer to FIGS. 1-13 for illustrative purposes. However, the flow diagram 1400 is not limited to the embodiment disclosed by FIGS. 1-13.

[0143] As mentioned above, the disclosed embodiments may use whether the page being rendered is a complex page to determine whether it should be saved or deleted. Alternatively, the disclosed embodiments may use the actual rendering time of the page to determine which pages to keep after the job is processed or printed. The disclosed embodiments may store the rendering data in memory 506, SSD 508, or HDD 510 depending on the type of job, and then the disclosed embodiments may choose to discard the rendering data for pages that were processed faster than the required engine speed, since the data can be regenerated without impacting production. In embodiments that alternate between memory 506 and SSD 508 or HDD 510, the disclosed embodiments may choose to do the same with the additional operation of moving pages from memory 506 to SSD 508 or HDD 510 to keep the rendered data for these pages.

[0144] A print job 103 is received and processed by the RIP system 110. As disclosed above, the front end 302 can provide each page of the print job 103 to the RIP system 110, and specifically to the renderer 418. The renderer 418 can determine an actual rendering time 1402 for processing the page 1105 within the RIP system 110. The rendering time 1402 may be determined before a page complexity determination is made.

[0145] Step 1404 executes by determining whether the rendering time 1402 is greater than or equal to a threshold value. This threshold value may be related to the engine speed 1308 disclosed above. In other words, step 1404 determines whether the speed at which the page 1105 is rendered is greater than the engine speed 1308. If so, this feature indicates that re-rendering the page 1105 will not impact the print engine 260. If the rendering time 1402 indicates that the page 1105 cannot be rendered to meet or exceed the engine speed 1308, then the page 1105 should be stored so as not to impact processing in the print engine 260 when the print job 103 is printed.

[0146] Thus, if step 1404 is Yes, step 1406 executes by removing page 1105 from the rendered pages stored in a repository, as determined by front end 302 or renderer 418. If step 1404 is No, step 1408 executes by writing page 1105 to storage. These embodiments make a preliminary determination of whether to discard a page without performing the complex page analysis disclosed above. In other embodiments, the page complexity determination process may be performed after the embodiment disclosed by flow diagram 1400.

[0147] In some embodiments, the determination of a complex page or rendering time may result in the indicated page being moved from memory 506 to SSD 508 or HDD 510. This feature may maintain available free space in memory 506 for types of jobs that are printed or processed later, such as process and hold or proof and hold. Thus, the embodiments disclosed in Figures 11-14 may be combined with those disclosed in Figures 1-10 to provide robust print operation management using multiple storage locations 602.

[0148] FIG. 15 illustrates a block diagram of an exemplary process for rendering a print job to multiple storage locations for printing operations according to disclosed embodiments. As shown in FIG. 15, the disclosed embodiments manage various storage locations in the printing system, namely memory 506, SSD 508, and HDD 510, for rendering pages of a print job. The disclosed embodiments can be used to manage multiple print jobs. The hierarchy of storage locations 502 disclosed above is maintained based on storage I / O efficiency, storage size, and job type. Rendering of a job starts from one storage area and automatically switches to another storage depending on system events and free space availability. These functions include allowing all components of the printing system to know where the rendering pages are located.

[0149] Act 1502 includes storing rendered page (1) of print job (1) in rendered page 630 of memory 506. Memory 506 has enough free space to store this page (1) of print job (1). Act 1504 includes storing rendered page (2) of print job (1) in rendered page 630 of memory 506. At this point, memory 506 may not be available. For example, after storing rendered page (2) in act 1504, memory 506 has no more free space. Thus, act 1506 includes storing rendered page (n) of print job (1) in rendered page 632 of SSD 508. Hierarchy 502 can indicate that SSD 508 is a place to store rendered pages if memory 506 is not available. The remaining pages of print job (1) may be stored in SSD 508. The front end 302 is notified that the locations of page(1) and page(2) of print job(1) are stored in memory 506 and page(n) is stored on SSD 508.

[0150] Because memory 506 is unavailable, pages of print job (2) are also saved to SSD 508. Operation 1508 includes storing page (1) of print job (2) in rendered pages 632 of SSD 508. However, after this operation, SSD 508 may indicate to front end 302 that there is also not enough free space available to store the remainder of the rendered pages of print job (2). Thus, hierarchy 502 indicates that the store operation moves to HDD 510 because HDD 510 has more additional storage space than memory 506 and SSD 508. As a result, operation 1510 includes storing page (n) of print job (2) in rendered pages 634 of HDD 510.

[0151] Copy job (3) may be a collated copy job as disclosed above. According to hierarchy 502, this type of job is not stored in memory 506, but is stored on SSD 508 or HDD 510. Because SSD 508 is unavailable, renderer 418 stores pages for copy job (3) in rendered pages 634 on HDD 510. Thus, operation 1512 includes storing multiple copies of page (1) of copy job (3) in rendered pages 634. Job (4) is a proof and hold job. According to hierarchy 502, proof and hold jobs are stored on one of the storage drives, not on memory 506. Because SSD 508 is unavailable, operation 1514 includes storing page (1) of job (4), which is a proof and hold job, in rendered pages 634 on HDD 510.

[0152] Process and hold job (n-1) is also received. Because it is also treated as a delayed job, it is also stored on HDD 510. Act 1516 includes storing page (1) of process and hold job (n-1) in rendered page 634 on HDD 510. Act 1518 includes storing page (n) of process and hold job (n-1) in rendered page 634. Thus, all of process and hold job (n-1) may be stored on HDD 510.

[0153] In one instance, page(1) and page(2) of print job(1) are printed. The rendered pages in rendered pages 630 may be deleted. Thus, when print job n is received at RIP system 110, the disclosed embodiments may determine that free space is currently available on memory 506. Because print job (n) is not a proof and hold job, a process and hold job, or a collated copy job, it may be stored on memory 506 if free space is available. Because front end 302 finds that free space is available, operation 1520 includes storing page(1) of print job (n) in rendered pages 630 of memory 506.

[0154] As will be appreciated by those skilled in the art, the present invention may be embodied as a system, method, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, all of which may be referred to generally herein as a "circuit," "module," or "system." Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium.

[0155] Any combination of one or more computer usable or computer readable media may be used. Computer usable or computer readable media may be, for example, but not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, devices, or propagation media. More specific examples of computer readable media (non-exhaustive list) may be electrical connections with one or more wires, portable computer diskettes, hard disks, Random Access Memory (RAM), Read Only Memory (ROM), Erasable Programmable Read Only Memory (EPROM, or Flash memory), optical fibers, portable Compact Disc Read Only Memory (CD-ROM), optical storage devices, transmission media such as those supporting the Internet or an intranet, or magnetic storage devices. It should be noted that computer usable or computer readable media may be paper or other suitable media. The program is captured electronically, for example, by optical scanning of paper or other media, and is compiled, interpreted, or processed in other suitable manner as necessary, before being stored in the computer's memory.

[0156] Computer program code for carrying out the operations of the present invention may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as the "C" programming language. The program code may run entirely on the user's computer, partially on the user's computer as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), and the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider).

[0157] The present invention will be described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to generate an apparatus. The computer or other programmable data processing apparatus creates means for performing the functions / acts specified in the blocks or blocks of the flowchart illustrations and / or block diagrams.

[0158] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of code constituting one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams or flowchart diagrams, and combinations of blocks in the block diagrams or flowchart diagrams, may be implemented by a special purpose hardware-based system or a combination of special purpose hardware and computer instructions that perform the specified functions or acts. The terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting of the present invention.

[0159] As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms unless the context clearly indicates otherwise. Furthermore, it will be understood that as used herein, the term "comprises" or "comprising" specifies the presence of stated features, integers, steps, operations, elements, or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or sets thereof.

[0160] The embodiments may be implemented as a computer process, a computing system, or an article of manufacture such as a computer program product on a computer readable medium. The computer program product may be a computer storage medium readable by a computer system and encoding computer program instructions for executing a computer process. When accessed, the instructions cause the processor to enable other components to perform the functions disclosed above.

[0161] Corresponding structures, materials, acts, and equivalents of all means or steps plus functional elements in the following claims are intended to include any structure, material, or act for performing a function in combination with other claimed elements specifically recited in the claims. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the disclosed form. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the invention. The embodiments have been selected and described in order to best explain the principles and practical applications of the invention and to enable those skilled in the art to understand the invention in the embodiments with various modifications suitable for the particular use contemplated.

[0162] One or more portions of the disclosed network or system may be distributed across one or more printing systems coupled to a network that can exchange information and data. Various functions and components of a printing system may be distributed across multiple client computer platforms or configured to perform tasks as part of a distributed system. These components may be executable, intermediate, or interpretive code that communicates over a network using a protocol. Components may have designated addresses or other designators to identify them within a network.

[0163] It will be apparent to those skilled in the art that various modifications can be made to what is disclosed without departing from the spirit or scope of the present invention. Therefore, the present invention is intended to cover the modifications and variations disclosed above, provided that such modifications come within the scope of the appended claims and their equivalents.

[0164] Furthermore, it goes without saying that the configurations and operations of the above-described embodiments are merely examples and can be modified as appropriate without departing from the spirit and scope of the present invention. [Explanation of symbols]

[0165] 100 Printing System 102 Client device 103 Jobs 104 Printing device 106 Controller 108 Print Management Server 110 RIP System 112 Documents 114 Quote 115 Applications 116 Preview 118 Raster Output 120 Display device 201 Computing Platform 202 CPU 204 Image forming unit 206 Memory Unit 208 Operation Panel 210 Network Communication Interface 211 Finisher 212 Paper Cassette 214, 602 Storage location 215 Command 216 Display section 217 Input section 218 Network communication processing unit 220 Printer Components 222 Copy Component 224 Scanner Components 226 Facsimile Component 227 Output Bins 230 Document Feeder Tray 260 Print Engine 262 Sensors 302 Front End 304 Spool drive 305 Cross Reference Table 306 Storage 400 RIP 401 Segments 402 Interpreter 404 Vector Objects 406 Raster Objects 408 Text Objects 409 Drawing Units 410 Drawing Services 412 Graphic Services 414 Font Rasterizer 416 Color Converter 418 Renderer 420 Bitmap Output 422 dot count value 500 I / O System 502 layers 504, 511, 1502, 1504, 1506, 1508, 1510, 1512, 1514, 1516, 1518, 1520 operation 506 Memory 508 SSD 510 HDD 512 Engine Manager 600, 700, 800, 900, 1000, 1100, 1200, 1400 Flow diagram 612, 614, 708, 808, 810, 910, 912 Page storage locations 630, 632, 634 Rendering Pages 703 Process & Hold Job 803 Proof & Hold Job 903 Collate Copy Job 1003 Suspend Job Command 1104 Complexity Flags Page 1105 Page 1302 Complexity Decision Engine 1304 Page Processing Weight Determination Engine 1306 page processing weight 1308 Engine Speed 1310 Basic page processing weight 1318 First Page Object 1320 Second Page Object 1322 Third Page Object 1323 Spot Color 1324 Page Objects 1325 Complexity Model 1326 Object Processing Weight 3081, 3082, 308n RIP instances

Claims

1. 1. A method for managing a printing operation, comprising: Receive a print job with multiple pages; Rendering at least one page of a first set of pages of the print job using a raster image processor (RIP) system; storing at least one rendered page of the first page set in a memory of a printing device receiving the print job; It is determined that the memory cannot be used, Rendering at least one page of a second set of the plurality of pages of the print job using the RIP system; storing the rendered at least one page of the second page set on a first storage drive in a hierarchy of storage drives accessible by the printing device, the first storage drive having a larger capacity than the memory; A printing operation management method comprising:

2. The first storage drive is a solid state drive or a hard disk drive.

2. The printing operation management method according to claim 1.

3. determining that the first storage drive is unavailable.

3. The printing operation management method according to claim 2.

4. and rendering at least one page of a third set of pages of the print job using the RIP system.

4. The printing operation management method according to claim 3.

5. storing the rendered at least one page of the third page set on a second storage drive in the hierarchy of storage drives accessible by the printing device; The second storage drive has a larger capacity than the memory.

5. The printing operation management method according to claim 4.

6. and notifying a front end in the RIP system that at least one page of the first page set is stored in the memory.

2. The printing operation management method according to claim 1.

7. determining, by the front end, that at least one page of the first page set has been printed.

7. The printing operation management method according to claim 6.

8. and deleting at least one page of the first page set from the memory.

8. The printing operation management method according to claim 7.

9. and discarding at least one page of the first page set if a rendering time of the at least one page of the first page set is less than a threshold.

2. The printing operation management method according to claim 1.

10. 1. A method for managing a printing operation, comprising: rendering at least one page of the first page set and at least one page of the second page set of the print job by a raster image processor (RIP) system; storing at least one rendered page of the first page set in a memory accessible by the RIP system; It is determined that the memory cannot be used, storing the rendered at least one page of the second page set on a first storage drive in a hierarchy of storage drives accessible by the RIP system, the first storage drive having a larger capacity than the memory; determining that at least one page of the first page set stored in the memory has been printed by a printing device; Removing at least one page of the first set of pages from the memory; Storing further rendered pages of the print job in the memory. A printing operation management method comprising:

11. and notifying a front end of the RIP system that at least one rendered page of the first page set is stored in the memory and that at least one rendered page of the second page set is stored on the first storage drive.

11. The printing operation management method according to claim 10.

12. and retrieving at least one page of the first page set to be printed by an engine manager of a RIP system, the front end instructing the engine manager that at least one page of the first page set is stored in the memory. The printing operation management method according to claim 11.

13. and notifying the engine manager that at least one page of the first page set has been printed by a print engine of the printing device.

13. The printing operation management method according to claim 12.

14. and notifying, by the engine manager, the front end that at least one page of the first page set has been printed.

14. The printing operation management method according to claim 13.

15. 1. A method for managing a printing operation, comprising: receiving a print job having a number of pages to be printed by a printing device; Rendering a first page of the plurality of pages by a raster image processor (RIP) system of the printing device; determining whether the first page is a complex page or a simple page; if the first page is a simple page, storing the rendered first page in a memory within a printing device; If the first page is a complex page, storing the rendered first page on a first storage drive in a hierarchy of storage drives accessible by the RIP system, the first storage drive having a larger capacity than the memory. A printing operation management method comprising:

16. The complex pages are rendered below an engine speed threshold and the simple pages are rendered above the engine speed threshold.

16. The printing operation management method according to claim 15.

17. and notifying a front end of the RIP system that the first page has been printed.

16. The printing operation management method according to claim 15.

18. If the first page is the simple page, then deleting the first page from the memory.

20. The printing operation management method according to claim 17.

19. If the first page is the complex page, then retaining the first page on the first storage drive.

20. The printing operation management method according to claim 17.

20. The rendering time of a complex page is equal to or greater than the processing time threshold, and the rendering time of a simple page is less than the processing time threshold.

16. The printing operation management method according to claim 15.

21. A printing system including a printing device, the printing device includes a print engine; a raster image processor (RIP) system for receiving a job having multiple pages and for providing rendered pages to a print engine; a memory for storing rendered pages from said RIP system; a hierarchy of storage drives accessible by the RIP system; The printing system Rendering at least one page of a first page set of a plurality of pages of the job; storing at least one rendered page of the first set of pages in the memory; determining that said memory is unavailable; Rendering at least a second page of a second set of pages of the job; storing at least one of the rendered second pages on a first storage drive in the hierarchy of storage drives accessible by the RIP system; A printing system comprising:

Images