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

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.