Patent Application
20100231952
Digital printing processes include the transmission or transport of digital data representative of a document to be printed to a digital printer, which takes the document data and produces a hard copy, printed, version of the document. Document data can be conveyed to the printer, for example, by the use of a printer language. The document data are converted into the appropriate printer language, typically by the software application used to generate the original document. The printer language then instructs the printer to create a rasterized image. Rasterization is a process of converting the data that describes the text and graphics into the format that is required by a printer's “print engine,” which is the machinery that actually puts the marks onto the page. Rasterization is performed by a raster image processor, often referred to as a “RIP,” and thus, the rasterization process is often referred to as “RIPping.”
With some systems, the RIP is a computer that is integral to the printer itself. Desktop printers, such as laser or inkjet printers, will typically have an integral RIP within the printer. With other systems, for example, larger commercial printers, the RIP is separate from the printer. In this case, the RIP is implemented in software that runs on a computer separate from, but connected to, the printer. In commercial applications, the RiPping process can be very resource intensive. High-volume print jobs can easily contain tens of thousands of pages that all have to be RiPped, requiring extensive amounts of processing power and memory space. Thus, the RiPping process often creates troublesome bottle necks in the overall printing process.
For these and other reasons, a need exists for the present invention.
In the following detailed description, reference is made to the accompanying drawings which form a part hereof, and in which is shown by way of illustration specific embodiments in which the invention may be practiced. In this regard, directional terminology, such as “top,” “bottom,” “front,” “back,” “leading,” “trailing,” etc., is used with reference to the orientation of the Figure(s) being described. Because components of embodiments of the present invention can be positioned in a number of different orientations, the directional terminology is used for purposes of illustration and is in no way limiting. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present invention. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present invention is defined by the appended claims.
In the following disclosure, specific details may be set forth in order to provide a thorough understanding of the disclosed systems and methods. It should be understood however, that all of these specific details may not be required in every implementation. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure the disclosed systems and methods.
It will also be understood that, although the terms first, second, etc. are used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another.
In some embodiments, the process illustrated in
The control module 20 generates a lookup ID for a reusable object within a job and determines whether the object is reusable within that job or across jobs. A hash, CRC or other suitable algorithm can be used to identify objects and determine their reusability status. Additional information regarding the reusable object is also identified, such as the location of the object within the print job.
An object that is reusable is often referred to as a resource. Certain printer languages facilitate identifying which resources are needed at a particular point in a print job. This allows a resource to be rasterized once and used many times, instead of being rasterized on each page and/or each print job in which it is used. An example of a print language for use with reusable content is personalized print mark-up language (PPML). PPML itself only defines how existing resources are combined to create pages, documents and jobs. For example, PPML defines where on a page a graphic object is to appear and the space into which it must fit. However, the attributes of the resources themselves are defined by further documents, or files, expressed in existing mark-up languages, such as Extensible Style Sheet Language Format Objects (XSL-FO), to which the PPML document refers.
Once the RIP 14 renders an object that has been determined to be reusable (either within the job or across multiple jobs), the RiPped object is saved to the cache 16 and assigned a lookup ID. In various embodiments the cache 16 can be implemented on a local file system, a remote file system, in a database, RAM or any other suitable data storage mechanism. When the RIP 14 processes the job and encounters an object that has been tagged as a previously RiPped asset, the RIP 16 simply inserts the previously rendered object data into the data output stream rather than re-RiPping the asset. This leads to a significant performance improvement, because for many jobs (such as photo, marketing collateral and other image intensive applications), the RiPping process is computer bound due to the nature of the complex assets.
In some embodiments, the cache 16 serves as a centralized cache so that multiple RIPs can access and write to the centralized cache.
Referring back to
The rasterized first, second and third objects 31a, 32a, 33a are then further processed by the print engine 12, resulting in the printed version 40 including the printed first, second and third objects 31b, 32b, 33b.
Having prior knowledge of where these reusable objects are located within a job and storing them in the cache 16 externally to the RIP 14 insures that after a job is profiled, the system can be re-configured to a state where the job is RiPped in the fastest time possible because the previously RiPped assets can be loaded into the RIP 14 prior to the job being processed. This is possible because the control module 20 has identified which reusable objects are required in every job or job portion and can instruct the RIP 14 to load the previously saved RiPped images from a certain location.
In this manner, print jobs can be reused once they have been RiPped. The control module 20 has a global view of the reusable objects within the job so it can instruct the RIP 14 to preserve in memory and/or save these reusable objects in a specific location (export) or database. When a second portion of the same job or a new job instance based on the same template is created, the RIP 14 will avoid re-RiPping these assets and complete the job faster.
Moreover, the control module 20 can instruct the RIP 14 to load the previously cached RiPped assets in order to prepare the system to receive a job or a family of related jobs. RiPped assets could be stored in a database with an algorithmically determined key for subsequent retrieval. This extends the single RIP cache management to a system level cache management.
Once a job or job portion is processed, it is routed to the RIP 14 that has the required RiPped assets, reducing the RiPping time. The overall job management for the RiPping stage is now improved since the control module 20 knows the job requirements, the available RiPped objects and each individual RIP status regarding reusable objects that have already been loaded in a RIP. This enables a best fit strategy between the RiPs and the job requirements. Whenever these requirements are not met, the control module 20 can change the RIP cache by instructing the RIP to load assets from known locations. Once an object is RiPped in a particular RIP, that object can be used by all other RiPs without extra computational cost.
In some embodiments, the RIP 14 provides an application programming interface (API) for read-only (RO) cache management with single RO level operations to preserve objects in cache, save to location, load from location, remove from cache, give list of all the RO present in cache, etc.
Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that a variety of alternate and/or equivalent implementations may be substituted for the specific embodiments shown and described without departing from the scope of the present invention. This application is intended to cover any adaptations or variations of the specific embodiments discussed herein. Therefore, it is intended that this invention be limited only by the claims and the equivalents thereof.
