Before joining the faculty complement at the School of Graphic Communication Management at Ryerson, I worked for a well-known colour separator and prepress house in downtown Toronto. In my role as prepress manager, I witnessed the full gamut of client-supplied files for output. There were the good, the bad, and the down right nasty. Microsoft Word documents (and PowerPoint for that matter!) fell into the third category. There were a lot of reasons why these Microsoft gems solicited a wide array of colourful vocabulary from the prepress operators, but one of the main reasons was that everything in those files was defined as RGB. In a world of PostScript and Scitex Brisque CT/LW workflows, RGB was not a prepress operator’s friend.
Of course a lot has changed in the last twenty years. PostScript 3 paved the way for PDF-centric PostScript workflows. PDF files themselves evolved in complexity and functionality, with transparency and layers, and more and more support for non-print objects like multimedia files. Native PDF interpreters, like Adobe’s PDF Print Engine came to market and were able to take advantage of these more complex PDF files in ways PostScript never could. And of course the products, and what we “print” has also changed. Today, there are many things that we print traditionally that are also repurposed for digital printing and electronic (screen) use. A perfect example of this repurposing happens with magazines. Most magazines nowadays are printed commercially, usually by web offset. The cover may be printed separately, perhaps sheetfed, or even digitally to take advantage of customization. All or parts of the magazine are repurposed for the web, and possibly the entire magazine is also repurposed for an electronic tablet edition. To that, add e-mail digests, RSS feeds, and so on, and things can get pretty complex.
Repurposing files can be very time-consuming and laborious. Often files are constructed for traditional printing processes (i.e. CMYK), and then deconstructed and reconstructed for other distribution methods. This type of workflow is not ideal. For one thing, images that have been converted from RGB to CMYK and then back to RGB will not look as good on screen as the original RGB file would have looked, because of the lower gamut of CMYK. Similarly, a file that has been converted to CMYK with the intent of printing on an offset press may not be ideal for output on a toner-based press or a high-speed inkjet web press.
The reality is that for the greatest repurposing flexibility, a document designed in a completely RGB colour space is ideal. Those of us with a prepress background know the term RIP Once, Output Many (ROOM). What I am talking about here is more of a Design Once, Repurpose Many (DORM). This concept can be difficult to accept, especially for those of us that laboured through countless evenings and weekends because a really big customer thought it would be a great idea to design their annual report in PowerPoint. The truth of the matter is RGB can make sense.
It is interesting to note that several of the current technologies being used in many print shops and premedia facilities around the globe can already support an output neutral workflow. The photo manipulation, illustration, and page layout programs, PDF files, and RIPs all have the potential of supporting a successful output neutral workflow, and even do a decent job of converting RGB to CMYK. My own initial tests have shown that the results can be quite good.
Despite some very positive initial testing, however, there are still some issues relating output neutral workflows that have to be considered quite carefully. While some of these issues may seem minor to some, they could be showstoppers to others. Whether you are at one end of this spectrum or the other, or somewhere in-between, it is worth doing your homework.
Application Set-Up and Colour Definition
The first step in moving to an all-RGB workflow is to make sure you, or your customers, are designing files for an all-RGB workflow. One aspect of this is leaving RGB images as RGB and letting the conversion to CMYK happen at the RIP. In fact, many printers and publishers I know do this already, and are quite happy with the results. Keeping images as RGB offers greater flexibility and better results when repurposing is necessary, and can even offer greater flexibility when it comes to photo manipulation and retouching. Less familiar, however, is the idea of working with RGB for all vector elements too. This definitely brought me out of my comfort zone at first.
Since output neutral workflows are RGB-centric, they rely heavily on ICC profiles to reference target output intents for proper colour conversion. With this is mind, it is important to use the right profiles from the very beginning. For example, if you were building files for a magazine, InDesign Settings may look like this:
Image 1: An Example of InDesign Colour Settings for RGB File Preparation
Similarly, your Photoshop settings might look like this:
Image 2: An Example of Photoshop Colour Settings for RGB File Preparation
As mentioned earlier, for a truly output neutral workflow, vector object colours should be defined as RGB (or spot), not CMYK:
Image 3: Defining Colours as RGB in Authoring Software
This can be difficult, especially for colours that require a specific CMYK breakdown. In order for RGB colours to print correctly, they will have to undergo a colour transformation. Depending on the colour settings and profiles used, as well as the colour engine that is used to do the colour transformation, the resulting CMYK colour may or may not be what you expect. This is because the RGB values have to be converted to LAB values and then from there converted to CMYK. Sometimes the conversion can be exact, sometimes it can be off just a little, and sometimes it can be off a lot.
Image 4: An Illustration of an RGB to CMYK Colour Transformation
The Gold colour shown in the screenshot above converts perfectly into the CMYK breakdown that is intended: C=20, M=30, Y=80, K=0. However, this is not always the case. For example, one of the most notorious problems with converting RGB has to do with pure black. In the case shown below, RGB black (0,0,0) converts into a 4-colour black with over 300% ink coverage. When dealing with small text and hairlines, registration of these 4-colour objects can be problematic.
Image 5: An Example of RGB Black being converted to 4-Colour Black Instead of 100% K
This issue can be further complicated when dealing with corporate colours. A company might have both a CMYK and RGB breakdown for a brand colour, but that doesn’t mean that the specified RGB colour will convert to the specified CMYK colour when a colour transformation occurs. Another concern to be wary of is out-of-gamut RGB colours. There could be a significant colour shift when these colours are converted to CMYK.
RGB-Friendly PDF Files
In order to take full advantage of designing in RGB, the files that will be processed for output must also fully support and retain RGB data. This is a deviation from what is current practice for many printers.
When it comes to files being used in print, the more predictable and repeatable the results are when processing the file, the better. For this reason many printers have adopted PDF/X-1a files as their preferred format for files used for print. PDF/X-1a files are stable, predictable, and, for lack of a better term, safe. Even the issues resulting from transparency flattening in PDF/X-1a files have lessened over the years.
Many of the qualities of a PDF/X-1a file that make it a well-suited file format for print are prohibitive when it comes to an output neutral workflow. It is impossible for a PDF/X-1a file to have non-flattened transparency, or to use a colour space other than those used for print. In other words PDF/X-1a files are early binding in that all transparency must be flattened and all colours converted to CMYK (or spot) at the time the PDF/X-1a file is generated. Despite the obvious drawback of having to convert everything from CMYK back to RGB for repurposing, there can be other issues. For example, it can be quite common for repurposed PDF/X-1a files to display white lines when viewed on monitors or tablets. These white lines, or artifacts, are a result of the flattened transparency within the file. They can also be a huge headache for publishers that are printing and producing digital editions of a title. Consequently PDF/X-1a is not a great file format for jobs that are being repurposed. An alternative to PDF/X-1a worth serious consideration is PDF/X-4.
PDF/X-4 files support transparency and RGB objects. Since transparency does not have to be flattened at the PDF creation stage, RGB colours used in transparent objects do not have to be transformed. In this sense, PDF/X-4 files are late binding, which makes them much better suited to file repurposing. The best part of this is that, like PDF/X-1a, PDF/X-4 is an ISO standard file format, which means there is some structure, and therefore predictability inherent in the file.
I find it interesting that despite the fact PDF/X-4 has existed since 2008, there are still many printers and publishers insisting on supplied files to be saved as PDF/X-1a. There is a good reason for this. Just as the rigidity of PDF/X-1a makes it reliable for print and not so great for repurposing, the flexibility of PDF/X-4 make this a file format great for repurposing, but less predictable for print. The later in the process the file is bound to the output, the less predictable it is. This is especially true if the wrong RIP settings are used for PDF/X-4.
If used correctly, however, PDF/X-4 can generate consistently predictable print results with the flexibility required for file repurposing. In order for a PDF/X-4 file to retain the RGB data of the application file, it is important not to convert colours when generating the PDF/X-4 file.
Image 6: When saving a PDF/X-4 File for Repurposing Do Not Colour Convert to Retain RGB Data
The RIP is Key
In order to take full advantage of the output neutral benefits of properly setting colours and profiles in application programs and saving jobs as RGB PDF/X-4 files, you need the right kind RIP and the right settings to drive it.
First, it is important to note that there is no such thing as transparency when it comes to PostScript. PostScript is based on an opaque imaging model: it cannot comprehend the idea of transparency. If you try to process a PDF/X-4 file through a traditional Common PostScript Interpreter (CPSI) RIP, one of two things will happen. Either the RIP will resolve all transparencies before RIPping, or you will get an error.
In order to take full advantage of PDF/X-4, and move closer to an output neutral workflow, we must abandon the legacy of PostScript and embrace Native PDF RIP architecture.
For those that have not switched over to a Native PDF RIP, such as the Adobe PDF Print Engine, the process may not be as daunting (or expensive) as one might think. Most of the major workflow vendors have been shipping their products with dual PostScript/PDF RIP architecture under the hood for some time. For example, Prinergy 4.0 from Kodak shipped with both RIPs installed. Switching from one to the other can be as easy as selecting from a pull-down menu (see screen shot from Prinergy below) or checking a box. In my own experience, I have been using PDF/X-4 and the Adobe PDF Print Engine RIP in Prinergy in all my classes since 2009. My students like to experiment and push the limits of technology, and often this resulted in problems when using PDF/X-1a and the CPSI RIP. I have noticed a drastic reduction in RIP and output errors since making the switch.
Image 7: Selecting the Adobe PDF Print Engine RIP in Kodak Prinergy
The second reason why the RIP is key to output neutral workflows has to do with the colour engine under the hood. Most RIP vendors have their own proprietary algorithms for managing and processing colour transformations. One of my colleagues often refers to this as the RIP vendor’s “secret sauce”. RIP vendors often have rules built-in to their RIPs that make handling vector RGB data more reasonable. For example, the RIP may automatically map 100% RGB black (0,0,0) to 100%K instead of breaking it down to 4-colour black. This “secret sauce” can be very useful when dealing with RGB files, as it can resolve a lot of issues historically caused by colour transformations.
While RIPs may help eliminate many of the conventional issues associated with RGB colour transformations, there may still be issues that arise, particularly with RGB colours that are out of gamut on a CMYK device. Another potential issue that can be an obstacle to embracing an output neutral workflow is that no two-RIP vendors have the exact same “secret sauce”. This means that you may get different results from the same file if that file is sent through different RIPs. This could happen, for example, if there are different RIPs driving digital print devices versus traditional platesetters, or if a job is being printed at more than one location, and each location uses different RIPs. There can also be issues if different plants are using the same RIP but with different settings, or the same RIP but different versions (e.g. Prinergy 5 versus Prinergy 6). In other words, late-binding, device independent (output neutral) PDF files are less suited to the blind exchange of data than more traditional, early-binding PDF files are. As you could imagine, this potential for variability adds a layer of complexity to the processing of device-independent PDF files, especially when processing of these files is not constrained to a single RIP. Extensive testing, monitoring, and of course, good communication are all necessary if considering an output neutral workflow.
Investigating Output Neutral Workflows
There is probably a lot of investigative work currently being done around the world to explore the feasibility of output neutral workflows. I am involved in two initiatives that I can speak to here.
Close to home, Magazines Canada is currently exploring the feasibility of output neutral workflows for magazine production through the work of the Manufacturing and Technology sub-committee of the Advertising Services Committee. Magazine publishers could potentially gain a lot from an output neutral workflow because it could drastically reduce the time and effort currently needed to repurpose files for web and tablet, while at the same time resolving some systemic issues that arise when using traditional PDF/X-1a files for tablet publishing.
The sub-committee has conducted preliminary tests based on a test-form designed to address some of the more common issues that are associated with an RGB workflow. Based on the initial round of testing, the test-form has been revised and the sub-committee is currently undergoing a second round of testing. It is too early in the process to make any predictions, but there have been both positive and negative outcomes so far.
On a more global scale, the Ghent Workgroup (GWG) held a meeting in Belgium in January to discuss many things, including the possibility of expanding the current GWG specifications to include some level of RGB support. This is in-line with the statement the GWG made in its GWG 2012 CMYK specifications whitepaper, where they said that the “GWG is in full agreement that a Best Practices document for device independent workflows needs to be published, and continues to investigate this.” I stress that these discussions are extremely preliminary, and a lot more discussion and investigation needs to be done.
Conclusion
In a CMYK world, there are a lot of legitimate reasons to be nervous about moving towards an output neutral workflow. It could mean a revolutionary change in the way PDF files are saved, processed, and RIPped. It could involve rethinking the way application programs are set-up and defined. It would require a very strict understanding and use of colour management. And of course, it introduces the possibility of increased variability in the final output (whether that be print or digital, or both). It is more difficult to achieve a blind exchange scenario with files, as there could be significant variability in the way RGB colour is transformed from one RIP vendor to another.
Despite these concerns, the fact of the matter is that, for more and more market segments, the need for fast, efficient and predictable cross-media distribution has already become a reality. The more time and effort that is required to prepare files for multi-channel distribution, the less profitable the job becomes. The idea of “one file to rule them all” (sorry Tolkien) is very appealing, especially if that file could be an industry-standard, ISO-governed, PDF/X file.
It will be interesting to see how the current explorations into output neutral workflows unfold. It will also be interesting if the changes to the PDF ISO spec (i.e. PDF 2.0) that will be proposed and possibly ratified as early as the end of this year will have an affect (positive or negative) on the progression to output neutral workflows. This is turn could have an impact on the next update to the PDF/X-4 standard and so on.
In my opinion, we are not quite ready as an industry to migrate confidently into fully output neutral workflows. But we are close. With a demand, technologies that are capable, and people willing to take some risks, we are on the cusp of something that has long been talked about but never quite been made practical. This could be a significant year for the progression of device independent PDF file creation. I am excited to be a part of it.
