Processing PDF without in-RIP color management

Twenty years ago it was common to find people RIPping jobs for production print with no color management. Indeed, many print service providers (PSPs), magazine publishers etc actively avoided it as being “too complicated” and “unpredictable”. You might read that as an indictment of their vendors for a lack of investment either in developing good product or in educating their users. Alternatively it might simply show that the printing companies were quite understandably risk-averse because it could be expensive if the client didn’t like the resulting color, especially in an environment like display advertising in a major magazine, or packaging for a major brand.

A decade after that more and more people (on both the buying and the printing sides) grasped the value of color management in print and were using it, but there was still a significant minority that had not managed to make the time to understand it. This is borne out by the uproar when Adobe ‘forced’ people to use color management by changing from using CMYK for the alternate color space for Pantone spots in Creative Cloud to using Lab1, and by the continuing demand for support for PDF/X‑1a, where everything has already been converted to press colorants before the PDF is made.

Now we’re in 2022, and the need for color management is accepted almost universally in print sectors that use an ink set based on CMYK. I phrased it that way because some of the industrial print space (textiles, ceramics, laminate flooring etc) have historically used many inks, but usually job-specific rather than CMYK. Some of those markets will continue to use job-specific ink sets as they transition to digital, while others would find a switch to digital extremely challenging without a concurrent switch to a color managed workflow2.

So, why am I writing this now?

It’s because I still talk to people who tell me that they don’t need to do any color management inside the RIP when processing PDF; they RIP it first and then apply color management.

I’m sorry, that just won’t work reliably and with maximum quality.

There was a time, back in the days when PDF 1.3 was the latest and greatest (which pretty much means last millennium) when a PSP could get away with this approach, because their customers were happy to define all their colors in CMYK and spots. As soon as they used anything else, including Lab or colors tagged with ICC profiles, they’d have to have some fallback to generate CMYK values from that data. It doesn’t need a full color management module (CMM), but they’d need something.

And then along came PDF 1.4, adding transparency. And transparency requires that you can convert colors between color spaces, potentially multiple times. That’s because PDF transparency includes the concept of transparency groups. Each group is one or more graphics that are blended with any graphics that are behind them in the design.

The blending depends on a number of parameters, the most obvious of which are the blend mode (Overlay, Multiply, Hard Light etc), and the blend color space. The result of rendering all graphics that are underneath the transparency group will be transformed from whatever space the RIP holds it in (often the CMYK for the output device) into the blending color space. The result of rendering all the graphics inside the transparency group itself is also transformed into the blending color space. Then the blend mode is applied, to do the actual transparency calculation, and the result is transformed back into whatever color space the RIP needs it to be in for further processing (again, often the CMYK of the output device). The blending color space is quite often sRGB, because that’s the default in a number of popular design applications.

So correct rendering of the transparency will often require color transforms between the color space in which graphics are specified (such as, maybe, an image tagged with an ECI RGB ICC profile), the blend color space (most commonly sRGB) and the output device color space (usually a specific CMYK). That’s just not possible without applying a pretty complete color management process during RIPping. And if you try to take short-cuts you’ll usually get a visually different result, sometimes very different.

Color transformation with transparency requires a full color management capability.

Even so, back in the early 2000s a PSP could avoid the need to upgrade software, process control and operator training by insisting that their customers supplied files in a format such as PDF/X-1a, which prohibited device-independent colors and transparency. But making a PDF/X-1a file from a rich design in a creative application requires a number of compromises affecting graphical elements that were originally specified in device independent colors, or which use transparency. Both risk degrading the quality of the final piece.

These days insisting on PDF/X-1a to avoid the need for color management in the RIP is no longer widely acceptable to customers3. And therefore neither is color managing after the RIPping is complete.

Your check-list is therefore:

  • Don’t use PDF/X-1a. In fact don’t use PDF/X-3 either. Both are two decades old. PDF/X-3 may allow device-independent colors, but both of them force the creation tool to flatten transparency, discard layers and a bunch of other potentially damaging procedures. It’s over ten years since PDF/X-4 was published, and that’s currently the best balance between capability and getting too far ahead of common usage in print workflows.
  • If you’re a print service provider, converter, industrial printing manufacturer or digital press vendor, don’t cut corners; use a workflow that applies the color management in or before the RIP4. It shouldn’t be hard; all the leading RIP vendors (and therefore leading press vendors, because they license technology from the RIP vendors) supply suitable systems.

About the author

Martin Bailey, consultant and former 0CTO, Global Graphics Software

Martin Bailey, consultant at Global Graphics Software, is a former CTO of the company and currently the primary UK expert to the ISO committees maintaining and developing PDF and PDF/VT. He is the author of Full Speed Ahead: how to make variable data PDF files that won’t slow your digital press, a guide offering advice to anyone with a stake in variable data printing including graphic designers, print buyers, composition developers and users.

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,  Twitter and YouTube

Notes
1 – If a spot color will be emulated using process inks on press, then using a CMYK alternate gives predictable color numbers in those inks, but is less good at producing a predictable color appearance. Using Lab for the alternate color space often leads to unpredictable color numbers on each separation, but a more predictable color appearance on the print. There is a benefit to both models, but when it comes to paying for printing the color appearance usually wins!

2 – if run-lengths on digital are long enough to justify warehousing a variety of inks, and changings inks on inkjet presses, it can be reasonable to stay with job-specific ink sets, especially if it’s difficult or expensive to make usable inks for all of CMY and K. As an example, the best Magenta ink for inkjet printing on ceramics is made with gold. Any move to using digital presses for short-run printing more or less requires a fixed ink set to allow for quick job changes without excessive waste, and that typically means CMYK+.

3 – and I say that as the chair of the committees that developed PDF/X for many years, first in CGATS and then in ISO.

4 – There are situations where applying color management in a color server before the RIP can be useful, especially when multiple presses will be used in parallel. This approach brings its own challenges around handling spot colors in the job that will be emulated on press, but can produce excellent results when used with care.

Digital press data rates – and why they matter

Following his post last week about the speed and scalability of your raster image processor, in this film, Martin Bailey, distinguished technologist at Global Graphics Software, explains how to determine how much raster image processor (RIP) power you need to drive a digital press by calculating the press data rate. It’s the best way of calculating how much RIP power you need in the Digital Front End (DFE) to drive it at engine speed and to ensure profitable printing.

Further reading:

  1. Harlequin Core – the heart of your digital press
  2. What is a raster image processor 
  3. Ditch the disk: a new generation of RIPs to drive your digital press
  4. Is your printer software up to the job?
  5. Where is screening performed in the workflow
  6. What is halftone screening?
  7. Unlocking document potential

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 LinkedInTwitter and YouTube

Speed and Scalability: two things to consider when choosing a RIP for your digital inkjet press

If you’re building a digital press, or a digital front end (DFE) to drive a digital press, you want it to be as efficient and cost-effective as possible. As the trend towards printing short runs and personalization grows, especially in combination with increasing resolutions, more colorants and faster presses, the speed and scalability of the raster image processor (RIP) inside that DFE are key factors in determining profitability.

For your digital press to print at speed you’ll need to understand the amount of data that it requires, i.e. its data rate. In this film, Martin Bailey, distinguished technologist at Global Graphics Software, explains how different stages in data handling will need different data rates and how to integrate the appropriate number of RIP cores to generate that much data without inflating the bill of materials and DFE hardware.

Martin also explains that your next press may have a much higher data rate requirement than your current one.

For more information about the Harlequin Core visit: www.globalgraphics.com/harlequin

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 LinkedInTwitter and YouTube

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

Direct™ product manager Ian Bolton explores the impact of using software that has evolved from traditional print processes to drive digital inkjet presses as they advance to print faster, in higher resolution, a wider variety of colors and applications. In particular, Ian focuses on the impact that rising data rates have on the workflow:

Digital press software evolved from traditional print processes has already reached its limit. Digital presses are becoming higher resolution – most are moving from 600 dpi to 1200 dpi, quadrupling the data. They’re also becoming deeper, with up to 7 drop sizes – and these drops are being made from a wider variety of colors. Digital presses are also becoming wider, up to 4 meters wide, and faster,  up to 1,000 feet per minute!

And what if you need to print where every item is different? For example, fully personalized – like curtains, flooring, wall coverings, clothing etc. All of these require software that can deliver ultra-high data rates.

Let’s look at how those data rates scale up as digital presses advance:

The next generation presses demand ultra-high data rates
The next generation presses demand ultra-high data rates

 

If we start with 600 dpi, 20 inches wide, 3 drop sizes and 100 m per minute, then that’s 120 MBps per colorant, which is not too challenging. But once we move up to 1200 dpi, we’ve now quadrupled the data to 480 MBps, which is the read speed of all but the most bleeding-edge solid state drives today.

With printhead, nozzle and roller technology improving, the rated speeds also increase, so what happens when we go up to 300 m per min? It’s now 1.4 GBps and you will need one of those bleeding-edge solid state drives to keep up, bearing in mind you will now be writing as well as reading.

And if we go wider to print our wallcoverings at 40 inches wide, we’re now at 2.8 GBps … and we want our walls to look great close up, so we might be using 7 drop sizes, which takes us up to 5.7 GBps … and this is all just for one colorant!

Based on these numbers, it should be clear now that, for this generation of digital presses and beyond, a disk-based workflow just isn’t going to cut it: reading and writing this amount of data to disk would not actually be fast enough and would require ridiculous amounts of physical storage. This is where software evolved from traditional workflows hits a barrier: the data rate barrier.

To solve this we need to go back to the drawing board. It’s similar to the engineering challenge of moving from propeller-driven aircraft to jets that could break the sound barrier. Firstly, you need to develop a new engine and then you need to commercialize it.

So, if you’re looking for software to power your first or next digital press it’s going to need the right  kind of software engine that isn’t based on disk technology so that you can drive your digital press electronics directly and smash through the data rate barrier. In other words, you need to go Direct.

To learn more about the impact of rising data rates and how you can futureproof your next digital press, visit our website to find out more about going Direct.

If you’re interested in calculating data rates take a look at this blog post where you can download your own data rate calculator: Choosing the class of your raster image processor

Further reading:

  1. Harlequin Core – the heart of your digital press
  2. What is a raster image processor 
  3. Ditch the disk: a new generation of RIPs to drive your digital press
  4. Is your printer software up to the job?
  5. Where is screening performed in the workflow
  6. What is halftone screening?
  7. Unlocking document potential
  8. Future-proofing your digital press to cope with rising data rates

About the author

Ian Bolton, Product Manager, Direct
Ian Bolton, Product Manager – Direct
Ian has over 15 years’ experience in industry as a software engineer focusing on high performance. With a passion for problem-solving, Ian’s role as product manager for the Direct™ range gives him the opportunity to work with printer OEMs and break down any new technology barriers that may be preventing them from reaching their digital printer’s full potential.

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 LinkedInTwitter and YouTube

What is a Raster Image Processor (RIP)?

Ever wondered what a raster image processor or RIP does? And what does RIPping a file mean? Read on to learn more about the phases of a RIP, the engine at the heart of your Digital Front End (DFE).

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. The process of RIPping a job requires several steps to be performed in order, regardless of the page description language (such as PDF) that it’s submitted in. Even image file formats such as TIFF, JPEG or PNG usually need to be RIPped, to convert them into the correct color space, at the right resolution and with the right halftone screening for the press.

Interpreting: The file to be RIPped is read and decoded into an internal database of graphical elements that must be placed on the output. Each may be an image, a character of text (including font, size, color etc), a fill or stroke etc. This database is referred to as a display list.

Compositing: The display list is pre-processed to apply any live transparency that may be in the job. This phase is only required for any graphics in formats that support live transparency, such as PDF; it’s not required for PostScript language jobs or for TIFF and JPEG images because those cannot include live transparency.

Rendering: The display list is processed to convert every graphical element into the appropriate pattern of pixels to form the output raster. The term ‘rendering’ is sometimes used specifically for this part of the overall processing, and sometimes to describe the whole of the RIPing process.

Output: The raster produced by the rendering process is sent to the marking engine in the output device, whether it’s exposing a plate, a drum for marking with toner, an inkjet head or any other technology.

Sometimes this step is completely decoupled from the RIP, perhaps because plate images are stored as TIFF files and then sent to a CTP platesetter later, or because a near-line or off-line RIP is used for a digital press. In other environments the output stage is tightly coupled with rendering, and the output raster is kept in memory instead of writing it to disk to increase speed.

RIPping often includes a number of additional processes; in the Harlequin RIP® for example:

  • In-RIP imposition is performed during interpretation
  • Color management (Harlequin ColorPro®) and calibration are applied during interpretation or compositing, depending on configuration and job content
  • Screening can be applied during rendering. Alternatively it can be done after the Harlequin RIP has delivered unscreened raster data; this is valuable if screening is being applied using Global Graphics’ ScreenPro™ and PrintFlat™ technologies, for example.

A DFE for a high-speed press will typically be using multiple RIPs running in parallel to ensure that they can deliver data fast enough. File formats that can hold multiple pages in a single file, such as PDF, are split so that some pages go to each RIP, load-balancing to ensure that all RIPs are kept busy. For very large presses huge single pages or images may also be split into multiple tiles and those tiles sent to different RIPs to maximize throughput.

The raster image processor pipeline. The Harlequin RIP includes native interpretation of PostScript, EPS, DCS, TIFF, JPEG, PNG and BMP as well as PDF, PDF/X and PDF/VT, so whatever workflows your target market uses, it gives accurate and predictable image output time after time.
The raster image processor pipeline. The Harlequin RIP includes native interpretation of PostScript, EPS, DCS, TIFF, JPEG, PNG and BMP as well as PDF, PDF/X and PDF/VT, so whatever workflows your target market uses, it gives accurate and predictable image output time after time.

Harlequin Host Renderer brochure

 

To find out more about the Harlequin RIP, download the latest brochure here.

 

This post was first published in June 2019.

Further reading:

1. Where is screening performed in the workflow

2. What is halftone screening?

3. Unlocking document potential


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 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

PDF/VT – bringing all the advantages of PDF workflow to the world of variable data printing

Martin Bailey, consultant and former 0CTO, Global Graphics Software

Standards for variable data printing (VDP) have come a long way since the first work by CGATS to develop a universal delivery format in the late 1990s. In 2010 the International Standards Organization published the PDF/VT standard, marking the first really effective specification for a reliable, vendor-neutral exchange of variable data jobs, both within and between companies.

A special type of the PDF file format, PDF/VT is specifically used for variable data and transactional printing in a variety of environments, from desktop printing to high volume digital production presses. Built on PDF/X, it therefore brings all the advantages of that standard in enforcing best practices for reproducible and predictable color and appearance to the variable data and transactional print worlds.

The industry is gradually realizing its value to improve quality, competitiveness and productivity, and I’ve been working with the PDF/VT Competence Center, especially with Christoph Oeters (Sofha), Paul Jones (Teclyn bv) and Tim Donahue (technical consultant) to produce a new set of Application Notes highlighting the benefits of using PDF/VT and the workflows that it enables.

The Application Notes explain how to make the highest quality and most efficient PDF/VT files to achieve the required visual appearance of a job, so if you develop software to read and write PDF/VT files, for example in composition tools, RIPs, digital front ends and imposition tools, or if you work on print workflow integration, you’ll find the notes really beneficial. They also show how document part metadata can be applied and leveraged for VDP specific production workflows.

Of course, there are wider benefits to using PDF/VT: The adoption of PDF/VT will allow the industry to finally move towards a reliable, vendor-neutral exchange of variable data jobs, simplifying the process of variable data printing significantly.

The application notes are free to download, pick up your copy here: http://www.pdfa.org/publication/pdfvt-application-notes/.

Let me know what you think of them – feedback is always welcome.

Additional reading:
Do PDF/VT right

Do PDF/VT right by Global Graphics Software

 

PDF/VT for personalized print by the PDF/A Competence Center

Read the press release from the PDF Association (http://www.pdfa.org/2016/01/pdf-association-publishes-pdfvt-application-notes-showcasing-the-benefits-for-variable-data-print-streams/)