Why does optimization of VDP jobs matter?

Would you fill your brand-new Ferrari with cheap and inferior fuel? It’s a question posed by Martin Bailey in his new guide: ‘Full Speed Ahead – how to make variable data PDF files that won’t slow your digital press’. It’s an analogy he uses to explain the importance of putting well-constructed PDF files through your DFE so that they don’t disrupt the printing process and the DFE runs as efficiently as possible. 

Here are Martin’s recommendations to help you avoid making jobs that delay the printing process, so you can be assured that you’ll meet your print deadline reliably and achieve your printing goals effectively:

If you’re printing work that doesn’t make use of variable data on a digital press, you’re probably producing short runs. If you weren’t, you’d be more likely to choose an offset or flexo press instead. But “short runs” very rarely means a single copy.

Let’s assume that you’re printing, for example, 50 copies of a series of booklets, or of an imposed form of labels. In this case the DFE on your digital press only needs to RIP each PDF page once.

To continue the example, let’s assume that you’re printing on a press that can produce 100 pages per minute (or the equivalent area for labels etc.). If all your jobs are 50 copies long, you therefore need to RIP jobs at only two pages per minute (100ppm/50 copies). Once a job is fully RIPped and the copies are running on press you have plenty of time to get the next job prepared before the current one clears the press.

But VDP jobs place additional demands on the processing power available in a DFE because most pages are different to every other page and must therefore each be RIPped separately. If you’re printing at 100 pages per minute the DFE must RIP at 100 pages per minute; fifty times faster than it needed to process for fifty copies of a static job.

Each minor inefficiency in a VDP job will often only add between a few milliseconds and a second or two to the processing of each page, but those times need to be multiplied up by the number of pages in the job. An individual delay of half a second on every page of a 10,000-page job adds up to around an hour and a half for the whole job. For a really big job of a million pages it only takes an extra tenth of a second per page to add 24 hours to the total processing time.

If you’re printing at 120ppm the DFE must process each page in an average of half a second or less to keep up with the press. The fastest continuous feed inkjet presses at the time of writing are capable of printing an area equivalent to over 13,000 pages per minute, which means each page must be processed in just over 4ms. It doesn’t take much of a slow-down to start impacting throughput.

If you’re involved in this kind of calculation you may find the digital press data rate calculator useful: Download the data rate calculator

Global Graphics Software’s digital press data rate calculator.
Global Graphics Software’s digital press data rate calculator.

This extra load has led DFE builders to develop a variety of optimizations. Most of these work by reducing the amount of data that must be RIPped. But even with those optimizations a complex VDP job typically requires significantly more processing power than a ‘static’ job where every copy is the same.

The amount of processing required to prepare a PDF file for print in a DFE can vary hugely without affecting the visual appearance of the printed result, depending on how it is constructed.

Poorly constructed PDF files can therefore impact a print service provider in one or both of two ways:

  • Output is not achieved at engine speed, reducing return on investment (ROI) because fewer jobs can be produced per shift. In extreme cases when printing on a continuous feed (web-fed) press a failure to deliver rasters for printing fast enough can also lead to media wastage and may confuse in-line or near-line finishing.
  • In order to compensate for jobs that take longer to process in the DFE, press vendors often provide more hardware to expand the processing capability, increasing the bill of materials, and therefore the capital cost of the DFE.

Once the press is installed and running the production manager will usually calculate and tune their understanding of how many jobs of what type can be printed in a shift. Customer services representatives work to ensure that customer expectations are set appropriately, and the company falls into a regular pattern. Most jobs are quoted on an acceptable turn-round time and delivered on schedule.

Depending on how many presses the print site has, and how they are connected to one or more DFEs this may lead to a press sitting idle, waiting for pages to print. It may also delay other jobs in the queue or mean that they must be moved to a different press. Moving jobs at the last minute may not be easy if the presses available are not identical. Different presses may require different print streams or imposition and there may be limitations on stock availability, etc.

Many jobs have tight deadlines on delivery schedules; they may need to be ready for a specific time, with penalties for late delivery, or the potential for reduced return for the marketing department behind a direct mail campaign. Brand owners may be ordering labels or cartons on a just in time (JIT) plan, and there may be consequences for late delivery ranging from an annoyed customer to penalty clauses being invoked.

Those problems for the print service provider percolate upstream to brand owners and other groups commissioning digital print. Producing an inefficiently constructed PDF file will increase the risk that your job will not be delivered by the expected time.

You shouldn’t take these recommendations as suggesting that the DFE on any press is inadequate. Think of it as the equivalent of a suggestion that you should not fill your brand-new Ferrari with cheap and inferior fuel!

 

Full Speed Ahead: how to make variable data PDF files that won't slow your digital press edited by Global Graphics Software

The above is an excerpt from Full Speed Ahead: how to make variable data PDF files that won’t slow your digital press. The guide is designed to help you avoid making jobs that disrupt and delay the printing process, increasing the probability of everyone involved in delivering the printed piece; hitting their deadlines reliably and achieving their goals effectively.

DOWNLOAD THE FREE FULL GUIDE HERE: https://bit.ly/fsa-pdf

To be the first to receive our blog posts, news updates and product news why not subscribe to our monthly newsletter? Subscribe here

About the author:

Martin Bailey, CTO, Global Graphics Software
Martin Bailey, CTO, Global Graphics Software

Martin Bailey first joined what has now become Global Graphics Software in the early nineties, and has worked in customer support, development and product management for the Harlequin RIP as well as becoming the company’s Chief Technology Officer. During that time he’s also been actively involved in a number of print-related standards activities, including chairing CIP4, CGATS and the ISO PDF/X committee. He’s currently the primary UK expert to the ISO committees maintaining and developing PDF and PDF/VT.

 

To be the first to receive our blog posts, news updates and product news why not subscribe to our monthly newsletter? Subscribe here

Follow us on LinkedIn and Twitter

Choosing the class of your raster image processor (RIP) – Part II

Part II: Factors influencing your choice of integration

If you’re in the process of building a digital front end for your press, you’ll need to consider how much RIPing power you need for the capabilities of the press and the kinds of jobs that will be run on it. The RIP converts text and image data from many file formats including PDF, TIFF™ or JPEG into a format that a printing device such as an inkjet print head, toner marking engine or laser plate-setter can understand. But how do you know what RIP is best for you and what solution can best deliver maximum throughput on your output device? In this second post, Global Graphics Software’s CTO, Martin Bailey, discusses the factors to consider when choosing a RIP.

In my last post I gave a pointer to a spreadsheet that can be used to calculate the data rate required for a digital press. This single number can be used to make a first approximation of which class of RIP integration you should be considering.

For integrations based on the Harlequin RIP® reasonable guidelines are:

  • Up to 250MB/s: can be done with a single RIP using multi-threading in that RIP
  • Up to 1GB/s: use multiple RIPs on a single server using the Harlequin Scalable RIP
  • Over 1GB/s: use multiple RIPs spread over multiple servers using the Harlequin Scalable RIP

These numbers indicate the data rate that the RIP needs to provide when every copy of the output is different. The value may need to be adjusted for other scenarios:

  • If you’re printing the same raster many times, the RIP data rate may be reduced in proportion; the RIP has 100 times as long to process a PDF page if you’re going to be printing 100 copies of it, for instance.
  • If you’re printing variable data print jobs with significant re-use of graphical elements between copies, then Harlequin VariData™ can be used to accelerate processing. This effect is already factored into the recommendations above.

The complexity of the jobs you’re rendering will also have an impact.

Transactional or industrial labelling jobs, for example, tend to be very simple, with virtually no live PDF transparency and relatively low image coverage. They are therefore typically fast to render. If your data rate calculation puts you just above a threshold in the list above, you may be able to take one step down to a simpler system.

On the other hand, jobs such as complex marketing designs or photobooks are very image-heavy and tend to use a lot of live transparency. If your data rate is just below a threshold on the list above, you will probably need to step up to a higher level of system.

But be careful when making those adjustments, however. If you do so you may have to choose either to build and support multiple variations of your DFE, to support different classes of print site, or to design a single model of DFE that can cope with the needs of the great majority of your customers. Building a single model certainly reduces development, test and support costs, and may reduce your average bill of materials. But doing that also tends to mean that you will need to base your design on the raw, “every copy different”, data rate requirements, because somebody, somewhere will expect to be able to use your press to do just that.

Our experience has also been that the complexity of jobs in any particular sector is increasing over time, and the run lengths that people will want to print are shortening. Designing for current expectations may give you an under-powered solution in a few years’ time, maybe even by the time you ship your first digital press. Moore’s law, that computers will continue to deliver higher and higher performance at about the same price point, will cancel out some of that effect, but usually not all of it.

And if your next press will print with more inks, at a higher resolution, and at higher speed you may be surprised at how much impact that combination will have on the data rate requirements, and therefore possibly on the whole architecture of the Digital Front End to drive it.

And finally, the recommendations above implicitly assume that a suitable computer configuration is used. You won’t achieve 1GB/s output from multiple RIPs on a computer with a single, four-core CPU, for example. Key aspects of hardware affecting speed are: number of cores, CPU clock speed, disk space available, RAM available, disk read and write speed, band-width to memory, L2 and L3 cache sizes on the CPU and (especially for multi-server configurations) network speed and bandwidth.

Fortunately, the latest version of the Harlequin RIP offers a framework that can help you to meet all these requirements. It offers a complete scale of solutions from a single RIP through multiple RIPs on a single server, up to multiple RIPs across multiple servers.

 

The above is an excerpt from our latest white paper: Scalable performance with the Harlequin RIP. Download the white paper here.

Read Part I – Calculating data rates here.

Choosing the class of your raster image processor (RIP) – Part I

Part I: How to calculate data rates

If you’re in the process of choosing or building a digital front end for your press, you’ll need to consider how much RIPing power you need for the capabilities of the press and the kinds of jobs that will be run on it. The RIP converts text and image data from many file formats including PDF, TIFF™ or JPEG into a format that a printing device such as an inkjet printhead, toner marking engine or laser platesetter can understand. But how do you know what RIP is best for you and what solution can best deliver maximum throughout on your output device? This is the first of two posts by Global Graphics Software’s CTO, Martin Bailey, where he advises how to size a solution for a digital press using the data rate required on the output side.

Over the years at Global Graphics Software, we’ve found that the best guidance we can give to our OEM partners in sizing digital press systems based on our own solution, the Harlequin RIP®, comes from a relatively simple calculation of the data rate required on the output side. And now we’re making a tool to calculate those data rates available to you. All you need to do is to download it from the web and to open it in Excel.

Download it here:  Global_Graphics_Software_Press_data_rates

You will, of course, also need the specifications of the press(es) that you want to calculate data rates for.

You can use the spreadsheet to calculate data rates based on pages per minute, web speed, sheets or square meters per minute or per hour, or on head frequency. Which is most appropriate for you depends on which market sector you’re selling your press into and where your focus is on the technical aspects of the press.

It calculates the data rate for delivering unscreened 8 bits per pixel (contone) rasters. This has proven to be a better metric for estimating RIP requirements than taking the bit depth of halftoned raster delivery into account. In practice Harlequin will run at about the same speed for 8-bit contone and for 1-bit halftone output because the extra work of halftoning is offset by the reduced volume of raster data to move around. Multi-level halftones delivered in 2-bit or 4-bit rasters take a little bit longer, but not enough to need to be considered here.

You can also use the sheet-fed calculation for conventional print platesetters if you so desire. You might find it eye-opening to compare data rate requirements for an offset or flexo platesetter with those for a typical digital press!

Fortunately, the latest version of the Harlequin RIP offers a framework that can help you to meet all these requirements. It offers a complete scale of solutions from a single RIP through multiple RIPs on a single server, up to multiple RIPs across multiple servers.

In my next post I’ll share how the data rate number can be used to make a first approximation of which class of RIP integration you should be considering.

 

The above is an excerpt from our latest white paper: Scalable performance with the Harlequin RIP®. Download the white paper here