Proofing, pre-flight and ink estimation

Ink and toner estimation

Ink and toner form a significant proportion of the costs of printing on a high-volume digital production press. It’s therefore valuable to be able to estimate in advance how much a job will cost to print so that you can plan appropriately. This data can be used to assist with inventory management, to improve the data used for future job estimates, or even to form a direct input to every job quote. From the press vendor’s point of view it’s also useful to be able to provide accurate and relevant data on print costs to prospective press buyers.

By rendering pages from the actual job file submitted (or pre-production proof job), and then analyzing the resulting raster, a very accurate estimate of colorant coverage and ink usage can be obtained.

Hard-copy proofing

If your customer is printing to a cut-sheet press with sophisticated paper input and output handling he may be using the press itself as a proofer. If the press doesn’t have the facility to divert pages to a different output route, or if they’re printing reel to reel, it can be inefficient to insert very short jobs into the page stream for proofing. They may therefore want to produce proofs on a different printer, but they need to be sure that the rendering for those proofs will exactly match what they’ll get off the press. Using the same RIP, with the same color management options etc, will give them exactly that.

Soft proofing

It’s becoming more and more common to use soft-proofing for final review of jobs before sign-off. Use the same RIP as you do on press and you can be sure that the page images that are approved will match what is printed. Proofs may be produced at any size and resolution to suit a variety of use cases from dedicated, color-managed, soft-proofing systems to page previews for web-to-print.

Thumbnail generation

Job management in your DFE user interface and workflows can be enhanced by providing page thumbnails to allow rapid identification of each job. The same RIP that you use for the press can produce those thumbnails as well. This can be done either as a separate pass through the RIP in its own right, or your customers can create them by down-sampling rasters produced at printer resolution after the RIP has completed the job.

Printing related jobs

There are many use cases where it makes sense to print the bulk of a job on a high-volume digital press, but to print other components on another device. One example might be in book printing, where the book block would be printed on the press, but covers could be produced on a slower device that can feed heavy-weight stock. If the same RIPs can be used for both outputs your customer has maximum flexibility in assigning rendering resources between the various devices, and can guarantee the same quality of output on both.

Pre-flight

There are a variety of tools available for preflighting PDF jobs before submitting them to a print service provider (or to validate that a job a PSP has received matches their minimum specifications). Those tools are very useful, but don’t guarantee that the job can be processed through the DFE without error.

Unfortunately a large percentage of PDF files in real-world workflows today do not fully conform to the PDF specification, let alone to restricted subsets such as PDF/X and PDF/VT. Deviation from the specification may be within the PDF objects themselves, or may be in embedded resources such as fonts or ICC profiles. Because of this every system that reads PDF files includes a number of workarounds to ensure that virtually all files will be processed as expected, even if they don't formally conform to the standard.

Unfortunately the set of workarounds included will differ between products from different vendors, between multiple products from the same vendor, and even between different versions of the same product. A classical preflight tool will not, therefore, give PSPs an absolute guarantee that a job will run through their DFE.

If the DFE implementation always stores the RIP output to a buffer (e.g. on disk) before outputting to the press the PSP can simply process the job as usual, and discard the rasters in the unlikely event that a job does not complete. If they’re rendering and delivering pages directly to the press itself, however, they need to be 100% sure that every PDF file will be processed correctly to avoid the possibility of wasting significant time and materials, especially on a web press. The best way to do that is to use a lightweight route through the RIP (e.g. by running the interpreter and disabling the rendering phase).