Printing operation management method and printing system for managing out-of-sequence rendering for printing operation

Abstract

To provide a printing system for managing out-of-sequence rendering.SOLUTION: A printing system includes a printing device that receives print jobs. The printing device includes a controller having a raster image processing (RIP) system that includes a RIP manager and at least one renderer. The RIP system renders a first copy of a plurality of copies. The first copy includes a page. After the page is printed, the page for the first copy is deleted from a storage. During printing of a subsequent copy, an engine manager detects that the page is not available in the storage for rendered pages. The RIP manager is instructed to re-render the page using a renderer assigned to perform out-of-sequence rendering to render the page for printing.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a printing system and associated method for rendering one or more pages of a print job in order. [Background technology]

[0002] For a print job, the pages of the job are first rendered and then sent for printing within the printing device. After the last copy of a page is sent to the printing device's print engine, the page is deleted to save space. Under certain circumstances, a page can be deleted from storage before it is printed or sent to the final print engine. If the print engine needs a deleted page, it must be rendered again, resulting in pages being rendered out of order.

[0003] Multiple jobs can be active. The deleted page either belongs to a job that is still rendering other pages, or to a job that has completed rendering. There is a technical requirement that the resources required to render an out-of-order page be available to process the out-of-order page, even though they may be occupied by other pages or other jobs. This "out-of-sequence" rendering disrupts the normal print flow during a print operation.

[0004] Furthermore, Patent Document 1 discloses an image forming apparatus that can properly perform image processing operations in a multifunction machine equipped with a large-capacity hard disk even if the hard disk cannot be used for some reason. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Japanese Patent Application Laid-Open No. 2000-138787 Summary of the Invention [Problem to be solved by the invention]

[0006] However, the above-described conventional techniques do not address the release of resources for processing out-of-order pages.

[0007] The present invention has been made in view of the above circumstances, and an object of the present invention is to provide an image forming apparatus that solves the above-mentioned problems. [Means for solving the problem]

[0008] A method for managing print operations is disclosed. The method includes processing a print job with a raster image processing (RIP) system associated with a printing device. The print job includes multiple copies of a document having at least one page. The method also includes rendering a page of a first copy of the multiple copies using the RIP system. The method also includes storing the page of the first copy in storage associated with the RIP. The method also includes determining that a storage threshold for storage associated with the RIP system has been reached. The method also includes deleting the page from the first storage after printing. The method also includes determining that the page of the first copy is not available in the storage for printing a subsequent copy of the document. The method also includes instructing a RIP manager to render the page. The method also includes assigning a RIP to the page. The method also includes rendering the page with the assigned RIP for subsequent printing. A method for managing print operations is disclosed. The method includes processing a print job with a raster image processing (RIP) system associated with a printing device. The print job includes multiple copies of a document having at least one page. The method also includes rendering a page of a first copy of the multiple copies using the RIP system. The method also includes storing the page of the first copy in a directory file associated with the RIP system. The method also includes determining that a directory file threshold limit for the directory file associated with the RIP system has been reached. The method also includes deleting the page after the first copy is printed from the directory file. The method also includes detecting that a page from the first copy is not available in the directory file for printing subsequent copies of the document. The method also includes instructing a RIP manager of the RIP system to render the page. The method also includes assigning a RIP to the page. The method also includes rendering the page with the assigned RIP for printing with the subsequent copies. A method for managing print operations is disclosed. The method includes processing a print job with a raster image processing (RIP) system associated with a printing device. The print job includes at least one or more pages. The method also includes rendering a first page of the multiple pages using the RIP system. The method also includes determining that a storage threshold of storage associated with the RIP system has been reached. The method also includes determining that the first page is a simple page for processing within the RIP system. The method also includes deleting the first page from storage associated with the RIP system. The method also includes detecting that the first page is not available in the storage for printing. The method also includes instructing a RIP manager of the RIP system to render the first page. The method also includes assigning a RIP of the RIP system to the first page. The method also includes rendering the first page with the assigned RIP for printing with the multiple pages. A method for managing print operations is disclosed. The method includes processing a print job with a raster image processing (RIP) system associated with a printing device. The print job includes at least one page. The method also includes rendering the at least one page for the print job using the RIP system. The method also includes printing the page with the printing device. The method also includes deleting the page from storage associated with the RIP system. The method also includes detecting an error in the printed page. The method also includes detecting that the page is not available in storage for reprinting. The method also includes instructing a RIP manager of the RIP system to render the page. The method also includes assigning a RIP of the RIP system to the page. The method also includes rendering the page with the assigned RIP for reprinting. A method for managing print operations is disclosed. The method includes processing a print job with a raster image processing (RIP) system associated with a printing device. The print job includes multiple copies of a document having at least one page. The method also includes rendering a page of a first copy of the multiple copies using the RIP system. The method also includes detecting that a page of the first copy is not available for printing subsequent copies of the document. The method also includes instructing a RIP manager of the RIP system to render the page. The method also includes assigning a RIP to the page. The method also includes rendering the page at the assigned RIP for printing with the subsequent copies. A printing device is disclosed. The printing device includes a print engine that performs printing operations. The printing device also includes a digital front end (DFE) having a processor and a memory. The DFE manages the printing operations in cooperation with the print engine. The memory stores instructions that, when executed on the processor, configure the processor to perform operations to process a print job with a raster image processing (RIP) system associated with the DFE. The print job includes multiple copies having at least one page. The operations further include rendering a page of a first copy of the multiple copies using the RIP system. The operations further include detecting that a page of the first copy is not available for printing subsequent copies of the document. The operations further include instructing a RIP manager of the RIP system to render the page. The operations further include assigning a RIP to the page. The operations further include rendering the page at the assigned RIP for printing with the subsequent copies. [Effects of the Invention]

[0009] According to the present invention, it is possible to provide a print operation management method that is capable of managing out-of-order rendering of print operations. [Brief explanation 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] 1 shows a diagram illustrating a printing system for managing jobs according to disclosed embodiments; [Figure 2] 1 shows a block diagram of components of a printing device for use in a printing system according to disclosed embodiments. [Figure 3] FIG. 1 illustrates a block diagram of a RIP system for use in processing jobs in a printing system according to disclosed embodiments. [Figure 4] 1 illustrates a block diagram of an exemplary RIP used in a RIP system according to disclosed embodiments. [Figure 5] 1 illustrates a block diagram of a RIP system used to manage printing operations according to disclosed embodiments. [Figure 6] 1 illustrates a flow diagram for managing print operations (spatial threshold limits) during out-of-order rendering processing, according to disclosed embodiments. [Figure 7] 10 illustrates another flow diagram for managing print operations (directory file threshold limit) according to disclosed embodiments. [Figure 8] 10 illustrates another flow diagram for managing a printing operation (simple page detection) according to disclosed embodiments. [Figure 9] 1 illustrates a flow diagram for determining page complexity in a RIP system according to disclosed embodiments. [Figure 10] FIG. 1 illustrates a block diagram of components used to determine page complexity in accordance with the disclosed embodiments. [Figure 11] 10 illustrates another flow diagram for managing a printing operation according to disclosed embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0011] Reference will now be made in detail to specific embodiments of the present invention. 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, which may be included within the spirit and scope of the appended claims.

[0012] A print job consists of a variety of pages. Some pages are simple and render 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 may only be rendered and printed at a later date, or may be process-and-hold jobs. Other jobs may only print a portion (one copy) and hold the remaining copies to be printed upon user request. Other jobs may require multiple copies to be printed. Managing print operations is complex, requiring time and storage and available space that varies depending on the type of job and the complexity of the pages within the job.

[0013] The disclosed embodiments illustrate an example RIP system that uses hybrid I / O, where some pages are rendered in memory and other pages are rendered to disk storage. Disk storage may refer to a mass storage drive in a hierarchy of storage drives. Several embodiments are implemented. In one embodiment, job pages are processed sequentially. Pages are rendered in allocated portions of the host's memory or in memory in the RIP system or the host's printing device controller.

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

[0015] The disclosed embodiments manage rendered pages based on storage availability. This functionality ensures that page renderings are available on demand, especially when they are out of normal rendering order. For example, several use cases may be defined when out-of-order rendering of pages is required. Pages may be deleted after the first copy of a multi-copy collated job, including a "proof and hold" job, is printed. This situation may occur when a critical space threshold (storage threshold) limit is reached while printing a long job. It may also occur when a directory file threshold limit is reached while printing a long job. Different file allocation tables have limits on the number of entries that can be stored in a directory. If the number of entries exceeds that limit, a failure may occur.

[0016] Another use case is when a critical space limit threshold (storage threshold) is reached, simple pages are deleted and complex pages are kept after rendering. A simple page is one that can be rendered at engine speed by the print engine. It also includes cases where the print engine wants to re-render a page, such as when white lines are detected on the page. Printed pages may be deleted when the document is printed, similar to normal printing operations.

[0017] The RIP system includes a RIP manager and an engine manager. When the engine manager notices that a page is missing, it sends a message to the RIP manager to re-render it. The engine manager then waits for a confirmation message from the RIP manager. The RIP manager manages the renderers and provides a free renderer to re-render the requested page. If all renderers are busy, the RIP manager uses various methods to take a renderer away from a job that is already in progress. The RIP manager then re-renders the requested page using the reallocated renderer.

[0018] When the RIP Manager has completed re-rendering the out-of-order page, it sends a rendered page message back to the Engine Manager. When the Engine Manager has consumed the re-rendered page, it sends an acknowledgment back to the RIP Manager and the out-of-order rendering process is complete. In this way, the "out-of-order" rendering of a page does not follow the normal print path of a print operation.

[0019] 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 terminals 102.

[0020] 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 more detail in FIG. 2. Printing device 104 also includes control unit 106, which is a controller, or digital front end (DFE), that facilitates processing of job 103. Control unit 106 also includes RIP system 110, which is disclosed in more detail below.

[0021] For example, the controller 106 may use the RIP system 110 to convert bitmap images, vector graphics, fonts, etc. associated with pages in the job 103 into a bitmap / rasterized representation of the page, such as C, M, Y, K pixels. The sum of the values ​​of pixels of a particular color in the 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, these image rasterization parameters may include calibration curves, paper definitions, ICC profiles, spot color definitions, TRCs, color conversion settings, ink or toner colorant limits, rendering intents, K preservation, CGR levels, maximum ink (colorant) densities, print margins, halftones, etc.

[0022] 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 print with ink, toner, 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 print device 104's head cleaning intervals, head clogging intervals, etc. 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.

[0023] 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 attempt to offload processing of the job 103 from the control unit 106 of the printing device 104. This functionality may be desirable if the control unit 106 does not have the processing power to process the job 103 in a production printing environment. Accordingly, 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 control unit 106 to offload processing for other processing. 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.

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

[0025] For preview jobs, 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 for review by an operator. 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 terminal 102 and the printing device 104. In other embodiments, the display device 120 may be incorporated within the client terminal 102 or the printing device 104.

[0026] 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 result in different outputs, such as a document 112, a quote 114, or a preview 116. The RIP instances within the RIP system 110 are configured depending on the type of job 103 received.

[0027] 2 illustrates a block diagram of components of printing device 104 according to disclosed embodiments. The architecture illustrated in FIG. 2 may be applied to any multifunction printing or image forming device that performs various functions, such as printing, scanning, saving, copying, etc., within printing system 100. As disclosed above, printing device 104 may send and receive data from client terminal 102, print management server 108 if it is a separate device, and other devices within printing system 100.

[0028] 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 (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 can be configured to perform various operations, such as scanning, copying, printing, receiving or sending facsimiles, or document processing. As such, the printing device 104 may be a multifunction peripheral (MFP) that includes one or more functions of a printer, scanner, copier, facsimile machine, and printer. To provide these functions, the printing device 104 includes a printer component 220 that performs printing operations, a copier 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.

[0029] 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 sheets with the imaged surface to a tray after desired operations. The finisher 211 may also perform additional operations such as sorting the finished paper sheets, stapling the paper sheets, bi-folding, scoring, punching, and folding.

[0030] The paper cassette 212 supplies paper to the various components 220, 222, 224, and 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 of 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 may be incorporated into a paper catalog stored in the controller 106. The paper cassette 212 may be removed for refilling as needed. Printed paper from the components 220, 222, 224, and 226 is placed into one or more output bins 227. The one or more output bins 227 may have a capacity such that they are capable of receiving completed print jobs before being emptied or printing must be paused. The output bins may include one or more output trays.

[0031] The document feeder tray 230 is a document processor input feeder tray, which may include a physical component of the printing device 104 for receiving paper sheets 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 within 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, the document feeder tray 230 may interact with the print engine 260 to perform desired operations.

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

[0033] The storage unit 206 may be comprised of volatile and non-volatile memory. Volatile memory may include random access memory (RAM). Examples of non-volatile memory 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 storage unit 206 may also include any combination of readable or writable volatile or non-volatile memory, along with other possible memory devices.

[0034] Computing platform 201 may include one or more processors, such as CPU 202. These processors may execute instructions 215 stored in one or more memory locations 214. By executing these instructions, the processors cause printing device 104 to perform various operations. A processor may also incorporate a special-purpose processing unit, such as an application-specific integrated circuit (ASIC) or a field-programmable gate array (FPGA). Other processors may be included to perform operations for components 220, 222, 224, and 226, among others. In other words, a particular processor may cause printing device 104 to operate as a printer, copier, scanner, and facsimile machine.

[0035] Printing device 104 also includes an operation panel 208, which may be connected to computing platform 201. Operation panel 208 may include a display 216 and an input 217 for facilitating user interaction 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 touch-sensitive to receive input from the user. In this manner, a user may interact with display 216. These components may be used to enter code or other information into printing device 104.

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

[0037] 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 by the computing platform 201 over the network, the network communication processor 218 decodes the received packets and delivers them 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 for the printing device 104.

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

[0039] 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 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 a page description language (PDL), sends instructions to operate the lower-level print engine 260 for the actual rendering of the image and the application of ink to paper during operation on the printing device 104. The RIP system 110 may be located within the DFE 106, as disclosed above. Alternatively, the RIP system 110 may be located on the print management server 108 and communicate directly with the print engine 260.

[0040] 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 specific operational state 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 misfed document, toner levels, and other operational conditions. The sensors 262 may also detect the number of pages printed or processed by the printing device 104. If the sensors 262 detect an operational problem or fault event, they 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.

[0041] Some errors have hardware-related causes. For example, if a fault, such as a paper jam, occurs in the finisher 211, the display 216 can 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 can display information about the jam error located in one of the paper cassettes.

[0042] Some errors may be firmware-related. For example, the network communication processor 218 may cause a firmware or software error. The display 216 may indicate that the error is firmware-related, display the corresponding error code, and provide recommendations for addressing the error, such as rebooting the device.

[0043] The storage 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 using 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, allowing a server to collect data from multiple devices in the printing system 100. The REST API and SOAP are application protocols used to transmit data in different formats, such as files, XML messages, and JSON messages. Using the applicable network communication protocol and application protocol, the printing device 104, like other printing devices in the printing system 100, sends and receives data from the client terminal 102 and the print management server 108.

[0044] 3 illustrates a block diagram of a RIP system 110 for use in processing a job 103 in a printing system 100 according to the disclosed embodiments. As disclosed above, the RIP system 110 may be located in the control unit 106 of the printing device 104. Alternatively, the RIP system 110 may be located in the print management server 108 so as to communicate directly with the print engine 260 of the printing device 104.

[0045] The RIP system 110 includes a RIP manager 302 and RIP instances RIP 308-1 (RIP(1)), RIP 308-2 (RIP(2)), and RIP 308-n (RIP(n)). A RIP instance may be a RIP configured by the RIP manager 302 to process a job 103. A RIP instance may be a standard RIP, a high performance RIP, an ultra high performance RIP, a preview RIP, an estimated RIP, or a failover RIP. All RIP instances and the RIP manager 302 operate in parallel with each other.

[0046] The RIP manager 302 performs various operations, such as spooling the job 103, managing the job 103, managing pages or segments of the job 103, managing RIP instances RIP 308-1, RIP 308-2, and RIP 308-n, managing drives, determining the PDL type of the job 103, distributing pages or segments of the job 103 to the RIP instances, sequencing (serializing) pages or segments of the job 103, and sending notifications within the printing device 104 or print management server 108.

[0047] The RIP manager 302 can receive a job 103 via the printing system 100. The job 103 may be received from the client terminal 102 via Internet Protocol within the printing system 100. The job 103 may be spooled by the RIP manager 302 and stored on a spool drive 304. The spool drive 304 may be a configurable drive. The RIP manager 302 identifies the PDL type of the job 103. Next, the RIP manager 302 creates a cross-reference table 305 in the spool drive 304, which serves as shared memory for the RIP instances RIP 308-1, RIP 308-2, and RIP 308-n. The RIP manager 302 may also create print ticket information in the spool drive 304.

[0048] The RIP manager 302 analyzes the job 103 to determine what type of job it is. The RIP manager 302 uses this information to determine the number and type of RIPs to use to process the job 103. These functions are disclosed in more detail below. Depending on the type of job, the RIP manager 302 configures RIP instances RIP 308-1, RIP 308-2, and RIP 308-n. The configuration operation can create RIPs with a specific number of renderers. For example, the RIP instance RIP 308-1 can be a standard RIP with a normal number of renderers, such as four. The instance RIP 308-2 can be a high-performance RIP with a greater number of renderers, such as six. The RIP manager 302 configures the RIP instances to process the job 103.

[0049] The RIP manager 302 then distributes the pages or segments of the job 103 to the RIP instances RIP 308-1, RIP 308-2, and RIP 308-n. The job 103 may be a print job that is divided into segments or pages for parallel processing. The RIP instance RIP 308-2 is a high-performance RIP, so it can receive specific pages or segments 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 a number of pages or a block of data within the job 103. The pages or segments are distributed by the front-end RIP manager 302 using inter-process communication.

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

[0051] The RIP instance renders the metadata to storage 306, which may store rendered pages for the 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 RIP manager 302 for further action.

[0052] The RIP system 110 offers advantages over traditional RIP systems. The RIP manager 302 can control the number of renderers per RIP. The RIP system 110 can increase the number of renderers to process pages or segments faster. The RIP system 110 can also increase the amount of memory allocated to a RIP, since faster processing consumes more memory. For slower processing, such as estimate 114 or preview 116, the configured RIP should consume less memory. The RIP manager 302 manages these requirements through dynamic configuration changes of the RIP based on job 103 parameters.

[0053] In some cases, the RIP manager 302 may determine that a job 103 cannot be divided into pages or segments for parallel processing. Therefore, a RIP instance, such as RIP instance RIP 308-n, may be configured as an ultra-high performance RIP. Ultra-high performance RIPs use more renderers than high performance RIPs. For example, RIP instance RIP 308-n may be configured to use eight renderers. This capability improves the processing speed of RIP instance RIP 308-n. The front-end RIP manager 302 may use RIP instance RIP 308-n to process one job 103 that cannot be divided into pages or segments, while still using RIP instances RIP 308-1 and RIP 308-2 to process another job 103 in parallel.

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

[0055] The RIP system 110 also provides the ability to change the number of renderers per RIP. The RIP system 110 may also change the number of RIP instances based on workload, including shutting down certain types of RIPs to start other types of RIPs. The RIP system 110 also processes different types of jobs with RIPs with different settings. The RIP system 110 also uses different RIPs with different configurations for different purposes. The RIP system 110 configures RIP instances with different imaging pipelines. The RIP system 110 also retries failed jobs or job pages on RIP instances with different configurations.

[0056] FIG. 4 shows a block diagram of an exemplary RIP 400 used within the RIP system 110 in accordance with the disclosed embodiments. RIP 400 can represent any of the RIP instances RIP 308-1, RIP 308-2, and RIP 308-n. RIP 400 can represent the hardware and software configuration used to determine what value each pixel or spot of output will have, driven by commands from a page description language (PDL). Computer-generated output can consist of very small spots. RIP 400 converts vector images, or stored images, into a series of mathematical formulas describing the lines and curves, and then into the pattern of spots needed to generate the output, or raster image. Interpreter 402 converts the job file into a display list, which is then converted into a bitmap output 420 describing the document pages.

[0057] 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 rasterizing a page implements several steps that are performed regardless of whether the page is submitted as PostScript, PDF, or another page description language (PDL). In short, the RIP 400 can provide interpretation, rasterization, and screening.

[0058] 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 code or bitmap code. As disclosed above, front-end RIP manager 302 receives job 103. Front-end RIP manager 302 may divide job 103 into segments for parallel processing by RIP instances. Preferably, segment 401 is a document page of job 103. Multiple RIPs process 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.

[0059] The 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 acts as a parser, converting the specific PDL into drawing commands. The PDL of the 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., and can be listed in the vector object 404, raster object 406, or text object 408.

[0060] The drawing component 409 receives vector objects 404, raster objects 406, and text objects 408 and converts the drawing commands into metadata that can be provided to a renderer 418. Thus, the drawing component 409 converts vector objects 404 to drawing services 410, raster objects 406 to graphics services 412, and text objects to a font rasterizer 414.

[0061] The RIP 400 may also implement a color converter 416. The color converter 416 can implement color conversion operations for the metadata generated by the renderer 409. The color converter 416 provides color management and calibration. These operations may be applied during interpretation or rendering, depending on the configuration and job content. Color printing resources may be taken into account to provide color management.

[0062] The renderer 418 processes the metadata from the drawing unit 409 and converts all graphic elements into the appropriate pattern of pixels to form the output raster. Resolution-independent vector objects 404 as drawing services 410 are converted into pixels. Screening takes the raster image of pixels and creates separate screened cyan, magenta, yellow, and black bands. These are halftone dots in the form of bitmap output 420, which consists of commands that the print engine 260 can understand.

[0063] 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 an estimate for the quote job estimate 114, as disclosed below.

[0064] 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 represents a single pass for rendering and providing output. Preferably, the RIP 400 represents multiple rendering passes using multiple renderers. In the disclosed embodiment, a renderer 418 may be used for each channel in 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 RIP manager 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 executes faster. A smaller number of renderers 418 in the RIP 400 consumes less memory but executes slower.

[0065] FIG. 5 illustrates another block diagram of a RIP system 110 for use in managing print operations according to disclosed embodiments. FIG. 5 may disclose additional components of the RIP system 110. For example, the RIP system 110 includes the RIP manager 302 and the renderer 418 disclosed above. Additionally, the RIP system 110 may include an engine manager 512, which is disclosed in more detail below. The RIP manager 302 may consider one or more pages 502 for the print job 103. The RIP manager 302 may determine whether the page 502 has already been rendered. If so, the page data for the rendered page is placed in a page queue 503. If the page 502 has not yet been rendered, it is passed to the renderer 418.

[0066] The renderer 418 renders each page of the print job as disclosed above. The renderer 418 then writes the rendered pages to the storage 306. If the storage 306 runs out of storage capacity, additional storage may be used. In some embodiments, the rendered pages may be saved to specific storage locations within the storage 306. These storage locations are provided by the renderer 418 to the RIP manager 302. The RIP manager 302 provides these storage locations, along with information about those pages in the page queue 503, to the engine manager 512. The engine manager 512 reads different storage locations based on the page data from the page queue 503 according to operation 511. The engine manager 512 then 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. Pages may be printed sequentially as they are retrieved from their respective storage locations and provided to the print engine 260.

[0067] After printing, the rendered page data is deleted from storage 306. Engine manager 512 may also send an acknowledgement 514 to RIP manager 302, which may then delete the rendered page data from storage 306. Alternatively, engine manager 512 may delete the rendered page data from storage 306. In some embodiments, RIP system 110 may include an acknowledgement queue 516, which is a queue of acknowledgements (awaiting acknowledgement), for holding acknowledgements 514 to provide to RIP manager 302.

[0068] 6 illustrates a flow diagram 600 for managing print operations (limit threshold limits) during out-of-order rendering processing, according to a disclosed embodiment. The flow diagram 600 may refer to FIGS. 1-5 for explanation. However, the flow diagram 600 is not limited to the embodiment disclosed by FIGS. 1-5.

[0069] In the operation of printing a collated copy of a job, pages of the job are rendered once, but may need to be printed multiple times. Rendered pages of a job may be deleted only after the last copy of the page is printed. The disclosed embodiment illustrates an out-of-order rendering use case. In this embodiment, printed pages are deleted when copies of the job are printed for the collated job. In flow diagram 600, pages are deleted after the first copy of the job is printed and a critical storage threshold is reached. Multiple printed pages can be deleted using various strategies. If the engine manager 512 cannot find a page in the rendered pages 616 in storage 306, it calls the RIP manager 302 to re-render the page. Once the re-rendering is complete, the page is available to the engine manager 512 and is printed.

[0070] This technique can also be used for "proof and hold" jobs. A proof and hold job is received by the printing device 104 and provided to the RIP manager 302 of the RIP system 110. While a proof and hold job may correspond to the print job 103 disclosed above, the term proof and hold is used here to describe the type of job. A proof and hold job is a type of job in which rendering occurs but only one copy (portion) of the job is printed. The printed copy is used to "proof" the job, allowing changes to be made as needed before the remaining copies are printed. The remaining copies are printed as requested by the operator.

[0071] Thus, a print job 103, or proof and hold job, is received by the RIP manager 302 for rendering and printing using the RIP system 110. The job may be divided into pages, such as page 502, with each page containing its own data to be rendered for the print operation. Operation 602 executes by determining whether the page has been previously rendered. If yes, the flow diagram 600 proceeds to operation 604. If no, the flow diagram 600 proceeds to provide the page to the renderer 418 for a rendering operation.

[0072] Operation 604 executes by determining whether the page is to be re-rendered. If yes, the RIP manager 302 can provide the re-rendered page directly to the engine manager 512 to provide the page to the print engine 260. In other words, the RIP system 110 prints using an out-of-order rendering process. A page being "re-rendered" may be a condition that determines whether the page is being rendered for the first time or was previously deleted and is being re-rendered a second time. If the page is to be re-rendered, it is not queued in the page queue 503 because the engine manager 512 needs the page immediately and is waiting to provide the page to the print engine 260. The re-rendered page is sent directly to the engine manager 512 during out-of-order rendering.

[0073] If operation 604 is No, the page is provided to page queue 503 to await retrieval by print engine manager 512, as occurs during normal printing operations. Thus, although the page may already have been rendered when it is provided to RIP manager 302, it is not subject to out-of-order rendering, i.e., it is not re-rendered. The rendered page is placed in page queue 503.

[0074] Operation 606 executes by determining whether a page is available in the rendered pages 616 in storage 306 or in the page queue 503. The engine manager 512 may execute a page read instruction to obtain the page to print in operation 621. It may also receive a re-rendered rendered page from operation 604. If the page is available, operation 606 proceeds to operation 608, which provides the rendered page data to the print engine 260 to print the page. The engine manager 512 may send the rendered page data to the print engine 260.

[0075] A print acknowledgement 514 (print acknowledgement) is provided to acknowledgement queue 516 and provided to RIP manager 302 after completion of operation 608. RIP manager 302 may generate a print page instruction as operation 609 and perform operation 610 to determine whether space is available in storage 306. In other words, RIP manager 302 or RIP system 110 can determine whether the rendered page 616 has reached a storage threshold for saving data to storage 306.

[0076] For example, the storage threshold may be 80%, or the storage threshold may be reached when the data storage is 80% or more full. In other words, there may be only 20% or less space available to store more rendered pages 616. If the data storage in storage 306 exceeds the storage threshold, certain actions may need to be taken. In the disclosed embodiments, it may be determined that only certain pages are stored in storage 306 because free space is needed for other print job processing operations.

[0077] Thus, if operation 610 is Yes, the printed page is deleted after the last copy is printed, as disclosed by operation 612. Once the page of the last copy of the multiple copies of the job is printed, it is deleted from storage 306 in operation 608. Otherwise, the page is not deleted and the print operation proceeds to the next page for printing.

[0078] If operation 606 is No and there is not enough space in storage 306, the page is deleted after the first copy is printed. Storage 306 cannot accept any more rendered pages 616. Therefore, the page is not stored as a rendered page and is not available for engine manager 512 to print in subsequent copies. Therefore, the page must be re-rendered.

[0079] Returning to operation 602, if the page has not been rendered, the determination is No. The renderer 418 is assigned to render the page, as disclosed above. After the rendering operation, the renderer 418 may perform operation 620 by writing the page to storage 306. It may also provide the rendered page 618 if the page is assigned to be re-rendered, as disclosed below.

[0080] Referring back to operation 606, if a page is not available to the engine manager 512 from the page queue 503 or storage 306, an out-of-order rendering process is performed. In some embodiments, the engine manager 512 generates a page re-rendering command to the RIP manager 302 in operation 622. The re-rendering page command or request may be held in the confirmation queue 516 until it is read by the RIP manager 302. Upon receiving the page re-rendering command in operation 622, the RIP manager 302 instructs operation 602 to assign a renderer 418 to render the page. If the renderer 418 is currently assigned to another job, the RIP manager 302 may take the renderer from that job and reassign it to render an out-of-order page from the print job 103. The renderer 418 provides the re-rendered page 618 to the RIP manager 302. The RIP manager 302 may provide the re-rendered rendered page directly to the engine manager 512 to perform the operation 608 of printing the page.

[0081] 7 illustrates another flow diagram 700 for managing print operations (directory file restrictions) during an out-of-order rendering process, according to a disclosed embodiment. The flow diagram 700 may refer to FIGS. 1-6 for explanation. However, the flow diagram 700 is not limited to the embodiment disclosed by FIGS. 1-6.

[0082] Flow diagram 700 can disclose a use case of an out-of-order rendering process in which pages are deleted when the first copy of a job is printed for a collation job. According to flow diagram 700, after the first copy of a job is printed, pages are deleted when the directory file threshold limit for directory file 701 is reached. If the engine manager 512 cannot find the page in directory file 701, it calls the RIP manager 302 to re-render the page. Once the re-rendering is complete, the page is available to engine manager 512 and is printed.

[0083] Flow diagram 700 includes features disclosed in flow diagram 600. Those features may not be repeated here for brevity. In summary, flow diagram 700 determines whether the page has been rendered. If not, renderer 418 renders the page. If so, flow diagram 700 determines whether the page has been re-rendered according to RIP manager 302 in response to a page re-rendering command from engine manager 512 in operation 622. If so, the re-rendered page is provided directly to engine manager 512 for printing. Otherwise, the rendered page is queued in page queue 503. In another embodiment, renderer 418 writes the page to an entry in directory file 701.

[0084] While printing a long job, the directory file threshold limit may be reached. The file allocation table may limit the number of entries that can be stored in the directory. If the number of entries exceeds that limit, a failure occurs. Entries may need to be deleted to stay within the directory file threshold limit. For example, directory file 701 may contain 40,000 entries, one for each rendered page. The files may contain file names with different identification numbers.

[0085] The threshold may be 80% of the number of entries in directory file 701, or 32,000 entries. When 32,000 pages have been stored in directory file 701 entries, the disclosed embodiments may determine that no more pages will be stored. Once the number of entries with pages reaches this threshold, additional rendered pages may not be stored in directory file 701. Therefore, they may be deleted. Referring to operation 702, it is determined whether the number of entries for rendered pages 618 in directory file 701 exceeds the threshold. If no, delete page operation 704 is performed by deleting the page if the most recently printed copy was the last copy of print job 103.

[0086] If operation 702 is Yes, the directory threshold limit has been reached and no more pages can be placed in the directory file 701 entry. Therefore, the page is deleted after printing the first copy of the print job. The RIP system 110 continues rendering subsequent pages without saving them for retrieval by the engine manager 512. The page has been printed and will be rendered again using the out-of-order rendering process disclosed above, except this process indicates that the page is no longer available in the directory file 701 or the page queue 503. The RIP manager 302 reallocates the renderer 418 from the current job to re-render the page. When the rendered page 618 is received by the RIP manager 302, it is provided to the engine manager 512 for printing along with the current copy of the print job so as not to hold up the printing operation.

[0087] 8 shows another flow diagram 800 for managing a printing operation (simple page detection) according to the disclosed embodiments. The flow diagram 800 may refer to FIGS. 1-7 for explanation. However, the flow diagram 800 is not limited to the embodiments disclosed by FIGS. 1-7.

[0088] Flow diagram 800 discloses a use case of an out-of-order rendering process in which a simple page is deleted. This situation can occur for long jobs with thousands of rendered pages ahead, or more than the print engine 260 can print. In flow diagram 800, the RIP manager 302 invokes the renderer 418 to render a page. If the rendered page is a simple page and a critical space threshold is reached, the page is deleted from storage 306, as disclosed above. At this time, the page information may still be queued in the engine manager 512.

[0089] If the engine manager 512 cannot find the page in storage 306 or page queue 503, it calls the RIP manager 302 to re-render it, as disclosed above. After being re-rendered by the renderer 418, the page becomes available to the engine manager 512 and is printed. In some embodiments, this process helps to pre-render complex pages so that the print engine 260 does not stall while waiting for the complex page to be re-rendered. Flow diagram 800 includes features disclosed in flow diagrams 600 and 700. These features may not be repeated here for the sake of brevity.

[0090] If, after operation 604, it is determined that the page will not be re-rendered as directed by RIP manager 302, operation 802 executes by determining whether there is free space available in storage 306. In other words, operation 802 determines whether a critical space threshold has been reached, as disclosed above. If free space is available, the page may be placed in page queue 503 to await retrieval by engine manager 512. In this case, rendered page 618 does not need to be deleted from rendered pages 616 in storage 306.

[0091] If operation 802 is No, operation 804 executes by determining whether the rendered page 618 is a simple page. In other words, the disclosed embodiments may determine whether the rendered page 618 is a complex page. According to the disclosed embodiments, 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 printing 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 be performed at a pace faster than the engine speed of the print engine 260. Rendered simple pages may fill (or eliminate) the limited storage space, or in other words, the compressibility (complexity) of the storage space, of the memory of the storage 306. The out-of-order rendering process of a simple page may be performed fairly quickly without occupying the resources of the RIP system 110.

[0093] 9 shows a flow diagram 900 for determining page complexity in the RIP system 110 according to a disclosed embodiment. The flow diagram 900 may refer to FIGS. 1-8 for illustration. However, the flow diagram 900 may not be limited to the embodiments disclosed by FIGS. 1-8. The flow diagram 900 may be implemented in the RIP system 110. For example, the flow diagram 900 may be implemented by the RIP manager 302 or the renderer 418. In other embodiments, the flow diagram 900 may be implemented elsewhere in the printing system 100, such as in the control unit 106.

[0094] A page 502 is received by the RIP system 110, which includes a renderer 418. The page 502 may be part of a job 103. According to the disclosed embodiments, it is determined that storage for the job's rendered pages is unavailable or limited, preventing the entire rendered page dataset from being saved. The disclosed embodiments determine whether the page 502 is complex. Operation 902 is performed by determining a page weight for the page 502. This process, disclosed in more detail below, is based on a set of rules and a weighted formula. Operation 904 is performed by determining whether the page weight is greater than or equal to a base page weight. The base page weight, disclosed in more detail below, is determined based on the engine speed of the print engine 260. Thus, determining whether a page is complex has implications for whether the page can be rendered "on speed" during a print operation.

[0095] If operation 904 is Yes, operation 906 marks page 502 as a complex page. If operation 904 is No, then page 502 is marked as a simple page in operation 908. Simple pages may be re-rendered using the out-of-order rendering process disclosed above.

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

[0097] The base page weight 1010 is related to the engine speed 1008 of the print engine 260 of the printing device 104. The engine speed 1008 may refer to the number of pages or sheets per minute that the print engine 260 can process, i.e., put ink on paper. This speed may refer to the average speed of a number of previous print jobs, or it may refer to the speed at which pages without objects are printed, such as text-only pages. The disclosed embodiments may assign a weight or value to the engine speed 1008.

[0098] For example, print engine 260 may have an engine speed 1008 of 150 PPM. This value may be based on previous print jobs and the engine speed for printing the pages of those jobs regardless of the content of those pages. Alternatively, the disclosed embodiments may obtain and use an engine speed for printing specific types of pages, such as text-only pages, pages with objects, pages with color printing, etc. Using this example, the base page weight 1010 for an engine speed 1008 of 150 PPM may be 10.0.

[0099] To determine the page weight 1006, the page weight determination engine 1004 may be implemented in the renderer 418 of the RIP in the RIP system 110. The page weight determination engine 1004 may also be implemented in the controller 106, the print management server 108, or elsewhere in the RIP system 110. The page weight determination engine 1004 may take into account page objects 1024 and object weights 1026 from the page 502. These features are disclosed separately below.

[0100] Page objects 1024 are objects on page 502, such as images, graphics, text, etc. within the page. For example, page 502 may include a first page object 1018, a second page object 1020, and a third page object 1022. The third page object 1022 may include a spot color 1023 necessary to print the third page object accurately. As disclosed above, objects may be of types such as vector, text, image, etc. Objects may be further categorized into operators such as form, shading, group, Type 3 character, pattern, font, color space, spot color, etc. For example, first page object 1018 may be a vector object with shading as an operator, second page object 1020 may be a text object with a particular font and several Type 3 characters as operators, and third page object 1022 may be an image object with spot color 1023 as an operator.

[0101] The disclosed embodiments can compile the page objects and their operators into a page object 1024 for the page 502. The page objects 1024 are provided to a page weight determination engine 1004. The page weight determination engine 1004 may use one or more weighting formulas to determine the weights of the page objects 1024. The weighting formulas may depend on object weights 1026 provided by a complexity model 1025. The disclosed embodiments collect statistical data and generate the complexity model 1025 based on these determinations. The complexity model 1025 is based on the object types disclosed above, or the various components of the page, such as vectors, text, images, etc. The objects in the complexity model 1025 may also be further categorized into operators.

[0102] When the page weight determination engine 1004 receives the page objects 1024 of the page 502, it can obtain object weights from the complexity model 1025. Alternatively, the page objects 1024 may be provided to the complexity model 1025, which in turn provides the page objects 1024 along with object weights 1026 to the page weight determination engine 1004. The first page object 1018 may be compared to similar page objects in the complexity model 1025 to obtain a weight for the first page object. The second page object 1020 may be compared to similar page objects in the complexity model 1025 to obtain a weight for the second page object. The third page object 1022 may be compared to similar page objects in the complexity model 1025 to obtain a weight for the third page object. In some embodiments, the object weights of the first page object 1018, the second page object 1020, and the third page object 1022 may be summed to determine the page weight 1006.

[0103] The page complexity determination engine 1002 applies a rule that if the page weight 1006 exceeds the base page weight 1010, the page is marked as complex. If the page weight 1006 exceeds the base page weight 1010, the page 502 is marked as a complex page. If the page weight 1006 is less than or equal to the base page weight 1010, the page 502 is marked as a simple page. Referring to the embodiments disclosed above, complex pages are stored in a memory location, while simple pages may be discarded.

[0104] Referring back to flow diagram 800, if operation 804 determines that the page is a simple page, operation 806 executes by deleting the page from storage 306. RIP manager 302 may instruct storage 306 to delete the page, or may instruct renderer 418 to delete the page. Therefore, engine manager 512 must instruct RIP manager 302 to re-render the page when printing in subsequent copies of print job 103. In other words, out-of-order rendering can be performed by assigning renderer 418 to re-render the page. If operation 804 returns No, operation 807 executes by waiting for storage space to become available. The page is determined to be a complex page and should be stored when storage space becomes available. This allows the page to be available to engine manager 512 for subsequent copies of the print job without having to be re-rendered.

[0105] In some embodiments, the RIP manager 302 may perform operation 808 to delete the printed page after receiving the print acknowledgement 514. If the printed page is determined to be a simple page, the engine manager 512 may notify the RIP manager 302 that the printed page may be deleted from storage 306 even if sufficient storage space is available because the page may be re-rendered in a manner that does not tie up the printing operation. If operation 808 is performed, the engine manager 512 may perform an out-of-order rendering process to obtain the rendered page by sending a page re-rendering instruction in operation 622.

[0106] In some embodiments, page information may be queued in page queue 503 for provision to engine manager 512. An unconditionally queued page may indicate that a page record or information is queued, regardless of whether the page is simple or complex. Here, rendered page data is not stored. The page record informs engine manager 512 of the location where the rendered page data is stored within RIP system 110. Engine manager 512 attempts to read the rendered page data from that location. If the data cannot be read, or if the page record does not provide a location because the page has been deleted, engine manager 512 can notify RIP manager 302 to re-render the page. This feature of the disclosed embodiments is applicable to flow diagram 600 and flow diagram 700 as well as flow diagram 800.

[0107] 11 illustrates another flow diagram 1100 for managing a printing operation according to the disclosed embodiments. The flow diagram 1100 may refer to FIGS. 1-10 for illustrative purposes. However, the flow diagram 1100 is not limited by the embodiments disclosed by FIGS. 1-10.

[0108] Flow diagram 1100 discloses a use case for out-of-order rendering when a defect is detected in a printed page or pages. The page may have already been deleted when the defect was detected. Therefore, print engine 260 requests that the page be re-rendered. This problem may be an abnormal condition that occurs in the normal printing flow, requiring the page to be re-rendered. Flow diagram 1100 includes features disclosed in flow diagrams 600, 700, and 800, which may not be repeated here for the sake of brevity.

[0109] The page may be rendered and printed as normal. Upon receiving the print acknowledgement 514, the RIP manager 302 may perform operation 808 by deleting the printed page from storage 306. However, during review of the printed page, operation 1102 may be performed by detecting defects on the printed page. For example, white lines may be detected. This detection may occur within the printing device 104 such that the print engine 260 is notified of the defects. The print engine 260 may then attempt to reprint the page without the defects. Thus, operation 606 is performed to determine whether the page is printable.

[0110] If operation 606 is Yes, print engine 260 can perform operation 608 by printing the page. If operation 606 is No, print engine 260 can instruct engine manager 512 to send a command to re-render the page to RIP manager 302 in operation 622. Alternatively, print engine 260 can send a command to re-render the defective page. Note that RIP manager 302 instructed storage 306 to delete the page printed pursuant to operation 808. Therefore, RIP manager 302 reassigns renderer 418 to perform an out-of-order rendering process to re-render the page and provides it to engine manager 512 for printing. If renderer 418 is processing another print job, RIP manager 302 can pull it from that job and have the defective page rendered so that print engine 260 can resume printing.

[0111] Note that the printing device 104 may detect the defect and automatically request the RIP system 110 to re-render the page. Alternatively, an operator may determine the defect and ask the printing device 104 to reprint. The printing device 104 may request the print engine 260 to reprint the page, which invokes the out-of-order rendering process.

[0112] As will be appreciated, the present invention may be embodied as a system, a method, or a 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.

[0113] Any combination of one or more computer usable or computer readable media can be used. Any combination of one or more computer usable or computer readable media can be used. Computer usable or computer readable media include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, devices, or propagation media. More specific examples (not an exhaustive list) of computer readable media include an electrical connection having one or more wires, a portable computer diskette, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a transmission medium such as one supporting the Internet or an intranet, or a magnetic storage device. It should be noted that the computer usable or computer readable medium can also be paper or other suitable medium on which the program is printed. This is because the program is captured electronically, for example, via optical scanning of the paper or other medium, compiled, interpreted, or otherwise processed in an appropriate manner as needed, and then stored in the computer's memory.

[0114] Computer program code for carrying out 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++, etc., and conventional procedural programming languages ​​such as the "C" programming language. The program code may execute 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), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider).

[0115] 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 produce an apparatus such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the function / method specified in the block or blocks of the flowchart illustrations and / or block diagrams.

[0116] 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 the specified logical function(s). 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 concurrently, 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, or combinations of blocks in the block diagrams or flowchart diagrams, may be implemented by a special-purpose hardware-based system that performs the specified functions or acts, or by a combination of special-purpose hardware and computer instructions.

[0117] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the present invention. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. Furthermore, as used herein, it will be understood that 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 groups thereof.

[0118] Embodiments may be implemented as a computer process, a computer 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.

[0119] Corresponding structure, materials, acts, and equivalents of all means or steps in the following claims, as well as functional elements, are intended to include any structure, material, or acts 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 to limit the invention to the form disclosed. 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 were chosen 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 various modifications suitable for the particular uses contemplated.

[0120] One or more portions of the disclosed network or system may be distributed across one or more printing systems coupled to a network capable of exchanging 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 interpreted code that communicates over the network using a protocol. Components may have designated addresses or other designators to identify them within the network.

[0121] 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 invention. Thus, it is intended that the present invention cover the modifications and variations disclosed above, provided that these modifications come within the scope of the appended claims and their equivalents. [Explanation of symbols]

[0122] 100 Printing Systems 102 client terminals 103 Jobs 104 Printing device 106 Control Unit 108 Print Management Server 110 RIP System 112 documents 114 Quote 115 Applications 116 Preview 118 Raster Output 120 Display Devices 201 Computing Platform 202 CPU 204 Image forming unit 206 Memory section 208 Operation Panel 210 Network Communication Interface 211 Finisher 212 Paper cassette 214 Memory Location 215 Command 216 Display section 217 Input section 218 Network communication processing unit 220, 222, 224, 226 components 227 Output Bins 230 Document Feeder Tray 260 Print Engine 262 Sensors 302 RIP Manager 304 Spool Drive 305 Cross Reference Table 306 Storage 308-1~308-n, 400 RIP 401 segments 402 Interpreter 404 Vector Objects 406 Raster Objects 408 Text Objects 409 Drawing Department 410 Drawing Services 412 Graphic Services 414 Font Rasterizer 416 Color Converter 418 Renderer 420 Bitmap Output 422 dot count value 502 pages 503 Page Queue 600, 700, 800, 900, 1100 Flow diagram 511,602,604,606,608,609,610,612,614,620,621,622,702,704,706,802,804,806,807,808,902,904,906,908,1102 operation 512 Engine Manager 514 Acknowledgment 516 Confirmation Queue 616, 618 Rendered Pages 701 Directory File 1002 Page Complexity Decision Engine 1004 Page Weight Determination Engine 1006 Pages Weight 1008 Engine Speed 1010 Base Page Weight 1018 First Page Object 1020 Second Page Object 1022 Third Page Object 1023 spot colors 1024 page objects 1025 Complexity Model 1026 Object Weight

Claims

1. 1. A method for managing a printing operation, comprising: processing a print job in a raster image processing RIP system corresponding to the printing device, the print job including multiple copies of a document having at least one page; Rendering a page of a first copy of the plurality of copies using the RIP system; storing a first copy of the pages in storage associated with the RIP system; determining whether a storage threshold for the storage associated with the RIP system has been reached; deleting the page from the storage after the first copy has been printed; Detecting that the page of the first copy is not available in the storage for printing a subsequent copy of the document; instructing a RIP manager of said RIP system to render said page; assigning a RIP to the page; Render the page on the assigned RIP and print it along with the subsequent copies. A printing operation management method comprising:

2. When the page is detected as unavailable, an engine manager in the RIP system is used to interact with the RIP manager.

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

3. When instructing the RIP manager, the engine manager sends the instruction to the RIP manager.

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

4. The engine manager exchanges data with the print engine of the printing device.

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

5. Further, the engine manager of the RIP system reads the pages of the first copy from the storage.

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

6. and printing the first copy on the printing device.

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

7. and deleting at least one page from the storage after the first copy is printed.

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

8. 1. A method for managing a printing operation, comprising: processing a print job in a raster image processing RIP system corresponding to the printing device, the print job including multiple copies of a document having at least one page; using the RIP system to render a page of a first copy of the plurality of copies; storing the first copy of the page in a directory file associated with said RIP system; determining that a directory file threshold limit for the directory file associated with the RIP system has been reached; deleting the page after the first copy is printed from the directory file; Detecting that the page of the first copy is not available in the directory file for printing a subsequent copy of the document; instructing a RIP manager of said RIP system to render said page; assigning a RIP to the page; Render the page on the assigned RIP and print it along with the subsequent copies. A printing operation management method comprising:

9. Detecting that the page is not available includes interacting with the RIP manager using an engine manager in the RIP system.

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

10. Instructing the RIP manager is sending instructions from the engine manager to the RIP manager.

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

11. 10. The method of claim 9, wherein the engine manager exchanges data with the print engine of the printing device.

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

12. and reading the first copy of the page from the directory file by an engine manager of the RIP system.

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

13. and printing the first copy on the printing device.

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

14. and deleting at least one page from the directory file after the first copy is printed.

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

15. A method for managing a printing operation, processing a print job in a raster image processing RIP system corresponding to a printing device, the print job including a plurality of pages; Rendering a first page of the plurality of pages using the RIP system; determining a storage threshold for storage associated with the RIP system; determining that the first page is a simple page for processing within the RIP system; deleting the first page from the storage associated with the RIP system; Detecting that the first page is not available in the storage for printing; instructing a RIP manager of said RIP system to render said first page; assigning a RIP of the RIP system to the first page; Rendering the first page along with the plurality of pages on the assigned RIP for printing. A printing operation management method comprising:

16. Furthermore, the printing device prints the first page together with the plurality of pages.

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

17. further rendering a second page of the plurality of pages using the RIP system; determining that the second page is a complex page for processing within the RIP system; Storing the second page in the storage associated with the RIP system 16. The printing operation management method according to claim 15.

18. and detecting that the first page is unavailable, using an engine manager of the RIP system.

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

19. The engine manager exchanges data with the print engine of the printing device.

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

20. Furthermore, the first page is placed in a page queue of the RIP system.

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

Images