Premedia (or prepress, if you prefer) has evolved quite significantly from the days of film stripping, vertical cameras and contact frames. Premedia, as we know it today, has been shaped by the advancement of digital technology. It can be a challenge to keep up with the pace of technological change sometimes, especially when technologies that we need to cooperate with one another don’t always change in symbiotic ways, or at the same rate.
I like technological change. It keeps things interesting. Advancements in technology can make existing processes better, and allow for new and innovative ways to do things that could not be done before. Change for the sake of change, however, can be a dangerous thing. Sometimes advancements in technology in one area can spell trouble for cooperating technologies. Case in point: native vector-based transparency. I still remember the day we received our first Illustrator 9 file to output where the designer had used vector transparency. We basically had to recreate the file from scratch to get it to output to film successfully. Even now, despite many advancements in transparency flattening, there are still significant output issues that can arise when trying to resolve native transparency for print output, especially when spot colours are involved.
The problem with native vector transparency in design is not really a problem with transparency at all. The concept is quite well defined, and the results obtained from using vector-based transparency can be quite good. The problem really has to do with cooperating technologies that are used to process those transparent files, and in particular, limitations of PostScript.
PostScript and Transparency
PostScript has been a cornerstone for the advancement of the print industry. It has helped define modern desktop publishing as we know it, and has been a key player in advancement of output through devices like imagesetters, and later, platesetters. PostScript has defined the very nature of what we do, and is at the heart of some of the biggest workflows used in this industry.
As important as PostScript has been to the progression of this industry, there are some limitations with regards to what it can do. When PostScript was developed, the concept of native vector transparency did not exist. PostScript is based on an opaque paint model, and in the world of PostScript there can be no such thing as transparency. Transparent objects must be flattened (i.e. rasterized) to conform to the opaque paint model used by PostScript. Since most modern-day PostScript-based RIP systems use a Configurable PostScript Interpreter (CPSI) engine to RIP files, at some point PostScript comes into play, and transparency must be flattened. Even PDF files created in such a way as to retain transparency will have to be flattened early on in a PostScript workflow. This is why native vector-based transparency can be problematic. And while application programs tend to be revised and updated on 18- to 24-month cycles, PostScript has not had a significant update since the 1990s.
As application programs evolve, transparency continues to grow with regards to the range and complexity of features available to users. Transparency can be something as simple as adding a drop shadow to a text box in InDesign, or as sophisticated as using blending modes and opacity to meld coloured objects through complex vignettes. Even using alpha channels in Photoshop files to crop objects in InDesign constitutes transparent imaging to a degree. As these features become more and more integrated into the software, transparency is being used as a design tool with more frequency, which can result in more issues on output. When spot colour objects are subjected to transparency, the possibility of output errors increases, especially when transparent spot objects interact with transparent CMYK objects.
The Adobe transparent imaging model changes the dynamic of how colour is derived on a page when compared to the opaque imaging model. The stacking hierarchy of objects is important, since this object order will be used to calculate colour (Adobe refers to the stacked objects as a transparency stack). Transparency values are calculated based on the order of the objects in the stack and the relationship of those objects with the compositing rules that are used to define the transparent imaging model. The complexity of this computation is increased when one considers that each object is drawn with an associated backdrop, and that backdrop will usually consist of other stacked objects previously defined. All the while this is taking place, colour is being calculated at each unique point using a blend mode, which is a function of the object’s colour and the resulting object backdrop. Different objects within a stack can have different blend modes, resulting in a wide variety of colour option combinations. The resulting transparency is achieved through a series of computationally-derived overprints that are used to represent the blended colours created by transparency.
As you may imagine, colour space plays a significant role in the outcome of the blending colour space used to resolve transparent objects within this framework. Adobe’s blending colour space supports various device and ICC colour spaces, but has a unique relationship with spot colours. Although blending can be done on spot colours so that transparency can be applied, spot colours are not converted to a blending space unless they are first reverted to an alternate colour space. This can produce undesirable results when attempting to reconcile transparency for the purpose of flattening. When a file that has transparent spot objects combined with non-spot objects in a stack is flattened, it can be difficult to simulate the many possible result colours within that blend space, since the spot colours must be dealt with separate from the blend space. In other words, transparent spot objects can result in some really messed up results when the file is RIPped, as seen in the example below.
The more complex transparent effects become in application programs, the more likely we will see problems like this at the output stage when transparency has to be flattened early in a PostScript workflow. When it comes to RIPping files with complex transparent elements, PostScript and its opaque paint model may not be the best tool for the job anymore. Lucky for us, there is an alternative.
The Adobe PDF Print Engine
In 2006, Adobe announced the release of their PDF native RIP technology, the Adobe PDF Print Engine (APPE), and at the same time confirmed that development of PostScript would stop at PostScript 3. In 2008, version two of the APPE was released and is currently available in a variety of workflow systems on the market. The significance of APPE lies in the fact that it does not use PostScript to RIP PDF files, and, consequently, is not governed by the same restrictions as PostScript. Features such as native transparency and optional content groups, for example, can be maintained throughout an APPE workflow.
There are significant advantages to maintaining transparency right through to the output stage. At the point that transparency needs to be resolved in an APPE workflow, several important aspects of the output are known, and can be used to create more stable results on output. Variables such as the number of colours, output resolution and screening requirements are known and can be incorporated into the final transparency reconciliation. In general, transparency stacks have the potential to be reconciled with greater accuracy and consistency when reconciliation occurs at the end of the workflow, just prior to output.
Another advantage of a PDF native RIP interpreter is fewer file transformations. The less times the file is converted from one format to another, the less likely we are to get artifacts and errors. In a normal PostScript workflow, a file can start off as being saved as a PostScript file, then distilled into a PDF, then RIPped as PostScript by a CPSI RIP. Each time one of these transformations occurs, there is a potential for errors to develop. With a PDF native interpreter such as the APPE, a file can be exported directly out of a program like Adobe InDesign or QuarkXpress as a PDF file and remain in a PDF state right through to final output.
In order to take advantage of the perceived benefits of the Adobe PDF Print Engine, PDF files have to be created in such a way as to support the advanced features. When saving a PDF file to use with APPE, we need to use PDF version 1.4 (Acrobat 5) at a minimum in order to retain transparency. For printers that use PDF/X standards, this can pose a problem. Many printers and publishers in North America have adopted PDF/X-1a:2001 as a file submission standard. There are many advantages to using a PDF standard for file submission, including stability, consistency, predictability and accuracy.
At Magazines Canada, we endorse PDF/X-1a:2001 as a file format for digital ad submission because it is proven and provides relatively reliable outcomes. Unfortunately, PDF/X-1a:2001 is based on PDF version 1.3 which does not allow for the retention of transparency. So then the question becomes how do we reap the benefits of retaining transparency until output while at the same time maintaining the stability of a PDF/X standard? The answer: combine the Adobe PDF Print Engine with PDF/X-4. Now we’re talking.
PDF/X-4:2008
PDF/X-4:2008 is one of the latest in a series of PDF standards to be ratified by the International Standards Organization. PDF/X-4, like its other PDF/X counterparts; it falls under the umbrella of the ISO standard 15930 (PDF/X-4:2008 is 15930-7, whereas PDF/X-1a:2001 is 15930-1).
There are some significant differences between X-4 and previous X standards, especially when comparing X-4 to X-1a. In particular, X-4 retains transparency on output, has support for non-CMYK colour-managed workflows and has limited support of optional content groups. Other versions of PDF/X have also supported alternate colour space workflows (like X-3), but they have not been as widely adopted in North America as they have in Europe. Regardless, transparency is a feature that is new to X-4.
Since PDF/X-4 is an ISO standard, there is some predictability that comes with using it for print production. Files created using the PDF/X-4 standard are governed by its rules, and therefore conform to certain expectations. When a PDF/X-4 file is processed with the Adobe PDF Print Engine, many of the historic issues relating to spot colours and transparency are resolved, as you can see in the example below.
There is also an added benefit of using PDF/X-4 and APPE together when it comes to image to image trapping. When an image with a transparent background is placed overtop another image, and the PDF file is not flattened, those two images remain separate objects and therefore can be trapped. This opens up some great opportunities where none existed before.
The idea of using PDF/X-4 and APPE together can be an appealing one, especially when you think about those files that you know will always give you trouble. There are some things that should be considered, however, before you tread down this path. First, keep in mind that both the APPE and PDF/X-4 are still relatively new. The Adobe PDF print Engine is only in version two of its release, and unless you have upgraded your RIP recently, you may be still be at version one, or not have it at all.
As for PDF/X-4, there are a few things worth noting. First, PDF/X-4 is only fully supported in Creative Suite 4. While there is an option to export as PDF/X-4 from Creative Suite 3, this is a draft version that was released prior to the published specification. There are differences between the draft version and the published version, specifically with how colour is managed, so do your homework if you are still on CS3. Even if you are using CS4, it is interesting to note that the ISO specification states that PDF/X-4 is based on PDF version 1.6; however, the PDF/X-4 preset out of CS4 uses PDF version 1.4. Also, while optional content (layers) is recognized in PDF/X-4, it is non-configurable by the user, meaning you cannot export editable layers within your PDF/X-4 file. As with all new technology, a bit of caution and a good dose of testing can prevent some headaches down the road.
A Study of PDF/X-4 and APPE
This past March, I had the opportunity to present a paper at the 62nd Annual Technical Conference hosted by the Technical Association of the Graphic Arts (TAGA). The paper, co-authored by Christopher Smyth and myself, was based on extensive research done comparing PDF/X-1a and PDF/X-4 files processed by both CPSI and APPE RIP interpreters. The research project was commissioned by the Technical Standards Sub-Committee of Magazines Canada, and was conducted by Ryerson University and by key publishers and printers within the Greater Toronto Area.
The purpose of the research was to compare and contrast the different technologies by creating test files that would be considered exceptionally challenging in a typical magazine publishing advertising workflow and running them through multiple workflow systems as both PDF/X-1a and PDF/X-4 files. The research extended over many months, and several workflow configurations were included in the testing. The files created for the testing were made to be challenging: they pushed the boundaries of design to include all sorts of transparency including blending modes, opacity settings, alpha channels, mixed colour models and even transparent spot to CMYK blends.
The results of the testing were quite interesting for many reasons. For example, I was not surprised that the complex transparency used on the files output incorrectly when flattened early in the workflow, but I was surprised that PDF/X-1a files and PDF/X-4 files produced different errors when flattened. Even more interesting was that the errors were unpredictable and inconsistent from one workflow to another.
Another interesting outcome of the research was that we discovered that if spot colours are converted to process prior to flattening a PDF file, the result will be different when compared to the same file saved as a flattened PDF file without spot colours converted to process, or spot colours converted to process after the PDF file is created (i.e. in the RIP).
The most amazing outcome of the research, however, was the non-flattened PDF/X-4 files that went through the APPE RIP. No matter how complex we made the files, they RIPped correctly. We tried many different files, with many different settings, but in the end the PDF/X-4 files we created that were RIPped using the Adobe PDF Print Engine just worked. Every time. To me, that is encouraging. I am excited to watch these two technologies evolve, and I am sure they will only get better with time.
Looking Forward: PDF/X-4:2010
As part of the research process for the paper noted above, I had the fortune to converse with Dov Isaacs from Adobe, who is very much involved with the development of the PDF/X-4 specification. One interesting thing that came out of these conversations was a discussion about an update to the PDF/X-4 specification that could be in place this summer: PDF/X-4:2010.
One of the key differences between the existing specification and the 2010 specification will be the support for user-modifiable layers within the PDF file. This change will be of particular interest to anyone who benefits from optional content layers for versioning, packaging design, and so on. It will be interesting to see if PDF/X-4:2010 will replace the 2008 specification or be in addition to it. While the ability to work with optional content layers is appealing to some areas of the industry, others may not want that option. For example, the support for layers in PDF/X-4:2010 may make it less likely to be adopted as a specification for digital ad submission in magazine production since the increased variability could pose a challenge to the automation necessary to meet decreasing production times. I am waiting eagerly to see how this one plays out.
Conclusion
As application programs get more complex, and the boundaries of print production get tested, we need to explore all tools we have to meet these challenges. Both the Adobe PDF Print Engine and PDF/X-4 are relatively new, however, my own experiences with these technologies leave me very optimistic. They have passed all the challenges I have given them to date, and although there are still things to test, I feel the results so far are quite positive. I have been using the Adobe PDF Print Engine in the Kodak Prinergy workflow for over a year at Ryerson without any problems. This past summer we moved to APPE in our Agfa Apogee workflow, and I have used it for two semesters without a problem. The APPE RIP, in both workflows, has been stable and reliable. Add to this the flexibility of the PDF/X-4 file format, and the possibilities abound.
Every company is different, and I wouldn’t suggest APPE or PDF/X-4, on their own or together, as solutions for the masses. Having said this, if you think there is a fit for either or both of these technologies where you are, it could be worth the time to look into it, especially if you already have the technology in-house to play around with.
