[Link]Vast amounts of data can slow down your digital press resulting in wasted product or delayed delivery times.

In this post, Global Graphics Software's product manager for Mako, David Stevenson, explores the challenge of printing large amounts of raster data and the options available to ensure that data doesn't slow down your digital press:

The print market is increasingly moving to digital: digital printing offers many advantages over conventional printing, the most valuable of these is mass-produced, personalized output making every copy of the print different. At the same time digital presses are getting faster, wider, and printing at higher resolutions with extended gamut color becoming common place.

To drive the new class of digital presses, you need vast amounts of raster data every second. Traditional print software designed for non-digital workflows attempts to handle this vast amount of data by RIPping ahead, storing rasters to physical disks. However, the rate at which data is needed for the digital press causes disk-based workflows to rapidly hit the data rate boundary. This is the point where even state-of-the-art storage devices are simply too small and slow for the huge data rates required to keep the press running at full rated speed.

This is leading to a new generation of RIPs that ditch the disk and RIP print jobs on the fly directly to the press electronics. As well as driving much higher data rates, it also has the benefit of no wasted time RIPping ahead.

As you can imagine, RIPping directly to the press electronics presents some engineering challenges. For example, two print jobs may look identical before and after printing, but the way in which they have been made can cause them to RIP at very different rates. Additionally, your RIP of choice can have optimizations that make jobs constructed in certain ways to RIP faster or slower. This variability in print job and RIP time is a bit like playing a game of Russian roulette: if you lose the press will be starved of data causing wasted product or delivery delays.

With a RIP driving your press directly you need to have confidence that all jobs submitted can be printed at full speed. That means you need the performance of each print job and page to be predictable and you need to know what speed the press can be run at for a given combination of print Job, RIP and PC.

Knowing this, you may choose to slow down the press so that your RIP can keep up. Better still, keep the press running at full speed by streamlining the job with knowledge of optimizations that work well with your choice of RIP.

Or you could choose to return the print job to the generator with a report explaining what is causing it to run slowly. Armed with this information, the generator can rebuild the job, optimized for your chosen RIP.

Whatever you choose, you will need predictable print jobs to drive your press at the highest speed to maximize your digital press's productivity.

If you want to know more about the kind of job objects and structure that can slow RIPs down, and the challenge of producing predictable jobs, download this guide: Full Speed Ahead - how to make variable data PDF files that won't slow your digital press.

You can also find out more about software to optimize both PDFs and non-PDFs for your digital press by visiting our website.

Further reading:

Is your printer software up to the job? The impact of rising data rates on software evolved from traditional print processes

Future-proofing your digital press to cope with rising data rates Be the first to receive our news updates and product news. Why not subscribe to our monthly newsletter? Subscribe here Follow us on LinkedIn, Twitter, and YouTube
  • Tweet
  • ' style='display: inline-block; line-height: 1; vertical-align: bottom; padding: 0px; margin: 0px; text-indent: 0px; text-align: center;'>Share

Attachments

  • Original document
  • Permalink

Disclaimer

Global Graphics plc published this content on 27 May 2021 and is solely responsible for the information contained therein. Distributed by Public, unedited and unaltered, on 27 May 2021 10:50:01 UTC.