Difficult PDF documents in prepress
By Jacob Schäffer
- PDF workflow specialist and Lead Developer of Grafikhuset Publi PDF,
Grafikhuset (House of Graphics)
First published: 02. September 2002.
Revised 12. April 2006.
Article contents
General PDF work flow basics »
Typical errors in PDF documents for prepress »
Which applications cause such trouble? »
Why can't they produce press-ready PDF documents? »
Can't these problems be solved? »
General PDF work flow basics
A true PDF workflow in prepress environments requires first of all
- High resolution PDF files, and
- Predictable behaviour in all aspects.
The Acrobat Distiller application from Adobe Systems handles the first point almost to perfection, if – and only if – the job settings are properly defined. The 'Predictable behaviour ...' point, however, is pretty often compromised by limitations or errors somewhere in the PostScript generation chain. There are various reasons:
- The operating system printer driver. On the Windows platform the primary cause is that most software relies on the printer driver. The printer driver is closely connected with the so-called GDI – an RGB device used to both display and print elements in RGB colour space only.
- The front-end application itself. Some applications generate their own PostScript, and even though they usually are capable of controlling things, this control is very dependent on the user not committing any error in the documents themselves or in placed artwork such as EPS documents.
- Insufficient knowledge. Too many end-users know far too little about fonts, colours, reproduction and printing technology. Hence, such users do not take at least the most common sources of error into consideration when they plan their prepress work.
Your degree of prepress success and efficiency is therefore directly related to how much back-end control you are able to exert over that above mentioned 'Predictable behaviour ...' point. It is simply very important to force 100% correct and predictable information into the PDF documents before the production flow is allowed to progress any further.
Otherwise a very unpleasant bill may teach you a lesson.
Typical errors in PDF documents for prepress
Many errors are typical for PDF documents designed for commercial printing:
- fonts are not embedded or included in subsets as recommended by the more or less official standards,
- the choice of compression is wrong,
- clipping of the document page doesn't allow edge-to-edge printing because the bleed margin is missing,
- wrong colour definitions caused by various sources, incl. misunderstood PostScript Colour Management
- etc., etc..
There are many applications available that check your PDF documents for common errors. Another story is whether or not such applications can correct the errors.
Some errors are quite easy to fix after the PDF documents are created, especially when you have a sufficient amount of relevant Acrobat plug-ins in your toolbox. Some errors can't be corrected at all in-PDF, because it's too late to correct them. And some errors can't be resolved as easily by in-PDF editing as with pre-PDF editing.
This article will concentrate on what I consider the most trouble-causing errors, namely those connected to wrong colour definitions caused by technical issues you don't have the slightest control of nor many chances for correcting after the PDF documents have been created. Such errors do occur – no matter what you do – when you create PDF documents from applications that prints through the printer driver on the Microsoft Windows platform – without regard to the version of Windows.
Which applications cause such trouble?
A lot more applications than you might think can not produce press-ready PDF documents for commercial printing via CTP (Computer To Plate) technology, even though Acrobat Distiller is configured properly and therefore, logically enough, is expected to do things right.
Among such applications is worth mentioning:
- Adobe FrameMaker, all known versions, Windows
- ArcView, all known versions
- AutoCAD (incl. the PS-Out filter)
- Crystal Reports, all known versions
- Older Corel VENTURA versions
- Corel WordPerfect Suite, all known versions
- Lotus SmartSuite, all known versions
- MapInfo, all known versions
- Microsoft Office, all known versions
- Microsoft Publisher, all known versions
- Microsoft Visio, all known versions
because these applications all are well known and widely used for different kinds of publishing in commercial printing – even though many printers hate to deal with such documents.
Acrobat Distiller can not be blamed for anything, however. Distiller actually does what it's told to do by the PostScript it receives – either directly by the 'Acrobat Distiller' printer or the contents of the .PS document you load into Acrobat Distiller for conversion to PDF.
Why can't they produce press-ready PDF documents?
All the mentioned applications prints through the system printer driver and is widely known as GDI printing applications.
They are called that because all elements in documents created by such applications are passed through the so-called GDI (Graphics Device Interface) both at display time and at print time. The quality of composite PostScript output with regard to a PDF workflow in prepress is therefore highly dependent on how the GDI and the printer driver itself behave.
On Windows this is critical, because the printer drivers on Windows – PSCRIPT, which follows Windows by default, and AdobePS, which optionally may be installed instead (non-clone interpreters only, though) – always print in the RGB colour space without regard to the type of colour device printing is set up for.
Composite CMYK colours or spot colour names and associated CMYK values are completely unknown to the printer driver. Thus, some colour information can't be passed through to a composite PostScript job nor a PDF document unless the application itself takes care of these things.
None of the mentioned applications bother to do so, neither when you create PDF documents directly via PDFWriter, PDFMaker or the 'Acrobat Distiller' printer instance nor when you print or export to PostScript first. They do pass EPS (Encapsulated PostScript) art through as is - namely unchanged. They still can't produce press-ready PostScript at all, which is needed for conversion to press-ready PDF format.
The consequences as a whole are:
- The colour of an imported or placed EPS graphic element will be different than that of a similar element drawn in the application, even though such elements have the same visual appearance as the EPS graphic on the display, and even though the same CMYK values are used for each (not all the mentioned applications support CMYK values).
- CMYK images (e.g. TIFF) are printed exactly as they are displayed - usually too saturated - because the CMYK values are converted directly to some RGB counterparts according to different, application specific rules I'm not 100% sure about.
- Grey images (e.g. TIFF, BMP, PCX etc.) are printed as indexed 8-bit RGB images, which explains why they often print on all CMYK plates when separated in a post-processing stage (e.g., by a Post-Script Level 2/3 RIP supporting in-RIP separations). Newer versions of the AdobePS driver engine offer some control of this, though.
- Vector graphics and text is usually printed in RGB colour space, which explains why for example, process black elements often print on all CMYK plates when separated in a post-processing stage (e.g. by a PostScript Level 2/3 RIP supporting in-RIP separations).
That's why many prepress professionals may advise you to avoid the above mentioned applications like the plague, even though the application you work with might be 'the ultimate' choice for other and more important reasons than 'just' PDF creation.
Can't these problems be solved?
Yes, definitely.
If you can work in a structured way and only store bitmap images such as scanned images or photos from digital cameras or GIS systems in a press-ready EPS (Encapsulated PostScript) format, e.g. with Adobe Photoshop, there is no reason whatsoever for abandoning any application at all.
You need to invest in a few additional tools, however. Even though some in-PDF editing plug-in modules for Acrobat partly can help with this, I'd strongly recommend you to learn how easily Publi PDF with Optimizer plug-in – a PDF creation software developed by Grafikhuset – can revert the colour information to the colours as originally intended before the Windows GDI and printer driver 'changed' it.
Publi PDF with Optimizer plug-in simply lets you take over the control of colours and lets you decide how colours are output to your final, CMYK or custom coloured, press- or Internet-ready PDF documents.
Copyright © Grafikhuset (House of Graphics), 2002, 2007. All rights reserved.