Episode III: The Search for Episode IV

Written by:

Jeff Horbinski
jhorbinski@gpo.gov



Author's Note: In late 2001 Scott Stovall began a four part series on Office Graphic (OG) applications. In fact, Scott did such a fine job he got himself promoted! While I can’t be certain that it was his OG article alone that got him noticed, I’d say that the chances are quite good. In any event, I picked up Scott’s material and will complete his work in this last installment, Episode III: The Search for Episode IV.

We have discussed, in gory detail, that OG files fail at every step for commercial printing. This final installment in the series will cover what workarounds a print vendor can do to try and output an OG file. As always, ePUB is available to answer any questions you have! Now, the conclusion...

 

Here is a review of the basic lessons from Part 2 of this series. There are seven areas where OG files fail the print industry:

  • Color: OG apps and files support RGB color only.
  • Page Integrity: Text reflow and loss of text is a common problem.
  • Prepress: OG apps and files do not support common prepress features.
  • Graphics Handling: OG apps and files do not properly handle .TIF and .EPS files.
  • Preflight: No feature exists, few preflight software programs support OG files.
  • Save & Package: Does not exist.
  • Image Creation: Does so poorly.
  • Those vendors that provide OG support do so only for additional money.

 

The Color Conundrum

In Part 2 of this series Scott discussed color issues with OG applications. What can’t be stressed enough is that color is the major issue barring OG applications from print publishing. To that end, a discussion of vendor workarounds necessitates a close look at color issues with OG files.
As previously discussed, customers who use OG software are typically users who are just beginning in print publishing who do not understand the commercial offset printing process. This statement is no insult to any of our customers; it is simply the truth of today’s printing industry. Many individuals are designing publications with little or no training in print publishing and, therefore, have unrealistic expectations regarding color. OG software deals almost exclusively with RGB colors. This is a fatal flaw found in almost all OG software and it is a fatal flaw because the printing industry works in either process (e.g., CMYK), or Spot (e.g., PANTONE, Toyo) colors. RGB values simply cannot be output for commercial printing without a conversion to either CMYK or spot colors.

Advances in vendor workflow over the past few years have allowed for more accessible RGB to CMYK conversion. Using tools like Adobe Acrobat in conjunction with a PDF editing tool or using in-RIP conversions, color can be converted out of RGB. However, consistency of color converted from RGB to CMYK has not been achieved. For example: The standard default blue in MS Word & MS Excel is an RGB blue that contains the values of R-19.9, G-39.8, and B-100. On screen and on some color printers the blue converts to a vivid, bright blue, similar to PANTONE PMS 300. However, when the file is converted to CMYK and printed on a commercial printing press, the blue becomes purple (similar to PANTONE PMS 2736).

To further complicate matters, the color palette in PowerPoint is different from the palette in Excel and Word. The most commonly used default blue in PowerPoint contains a different RGB value of R-19.9, G-19.9, and B-80.1. When color separated the blue is, well blue. Not the same as on-screen (looks PMS 300 on-screen), but discernibly blue, and not purple like the blue from Word or Excel. Is that confusing or what?

Vendors can also use certain tools to convert RGB to Spot colors, but another issue arises in this instance: converting to Spot colors typically requires extensive manual intervention. The most common method of handling spot colors in OG software involves converting the OG file to PDF and then editing the PDF in Adobe Illustrator or Enfocus Pitstop.

The final common color problem with OG applications centers on the RGB to CMYK conversion of black text (or images). CMYK color theory dictates that 100% C, 100% M, and 100% Y will generate “black.” In reality, those percentages yield a muddy brown! So, in conventional CMYK output, black text and black only images are produced from 100% K. This eliminates the muddy brown and registration issues that trying to align the C, M, and Y plates would yield with fine type. Unfortunately, the RGB values for black used by some OG software packages convert to that muddy, unregistered mix of C, M, and Y. Skilled print vendors will have a quality RIP that can do the in-RIP conversions resulting in 100% black. Others will need to make the conversion from RGB to CMYK, then convert the CMY text to 100% K resulting in extra effort and, therefore, extra cost to produce your publication.


Vendor Workarounds: Keep ‘Em Separated

I just mentioned an “In-RIP” separation as one of the tools a vendor could use to correct a file. What does that mean to you, the print buyer? Well, a Raster Image Processor (RIP) converts the data from your publication to pixels (raster data) so that the data can be output as dots from an output device such as an imagesetter, platesetter, or proofer. In the past, and in the workflow of most GPO vendor's, color separations are performed by the host applications (e.g., Quark XPress or Adobe PageMaker). The color separated data is then sent to the RIP, converted to raster data, and imaged to film, proof, or plate. However, many technically savvy vendors are opting for the ability to separate colors In-RIP, not through the host application. The main reason for this change is that it is easier for a vendor to compensate for color, and make the necessary production setting changes at the RIP rather than through the print interface of most host applications. An additional benefit is that most In-RIP workflows can process color data from any application. In other words, if you have an RGB image in a MS Word file and you have access to a RIP that performs In-RIP separations, you can make CMYK color-separated output. This color separation is automatic and requires no additional time or money from a print vendor.

As always, there is a catch. Each In-RIP device converts color data differently. And while some RIP's have even compensated for that RGB blue to CMYK purple color shift we discussed, the majority of RIP's do not. Therefore, even though In-RIP separation engines automatically convert RGB color to CMYK, the CMYK values of different devices will be different!

As you may have inferred from the previous paragraph, host-based separations are separations made prior to file submission to the RIP. The data is predefined and the RIP has little effect on how the colors are separated or plotted to film. Things such as screen angle, frequency, dot pattern, etc., are predetermined. The RIP does not control any aspect of the file and so outputting from OG applications yields less predictable results.

 

Vendor Workarounds: The PDF Cha-Cha

Adobe’s Portable Document Format (PDF) has been hailed as the savior of troubled files and the conqueror of print problems. While that pontification has yet to be 100% truth, PDF can be a great tool for vendors to work with your OG files. For readers who are not familiar with PDF, it is a file format created as a PostScript replacement. If you are familiar with PostScript, then the concept of PDF is this: PostScript that is visual and a true representation of the final product. This “locked” file format is cross-platform compatible with a relatively small file size and that makes it great for document exchange, especially across the Internet.

In the print industry, PDF is used as an intermediate format that can bridge the gap between layout file and imagesetter in certain workflows. As far as PDF and OG applications are concerned, OG files are converted to PDF and then edited with either Adobe Illustrator or a third party plug-in for Adobe Acrobat such as Enfocus Pitstop (featured in the Spring 2002 issue in the Digital Tools article). Most commonly, printers use a third party tool for work on PDFs. These tools allow for RGB to CMYK conversions, plus handy adjustments to things like stroke weight thicknesses, trap settings, and even text editing. The downside of these tools is that since PDF is a “locked” format, some portions of your OG file could remain unfixable.

 

Vendor Workarounds: Camera Copy Retreat!

The final file workaround is the industry’s version of Old Faithful: camera copy. That’s right, when all else digital fails: go analog! The printer will output a laser print of the file and then shoot it to film just like the good old days. This solution works best for simple one and two-color jobs because trying to get four-color film separations from a composite color laser is problematic at best. You might think: “Well why not print off color separated lasers and shoot those?” Good thought, but remember that those OG files are RGB and OG applications also lack the features that would allow you to print separated files in the first place.


Concluding the Conclusion on Office Graphics

Given enough time and money, GPO vendors can work with almost any file, and almost any file format. Realistically, however, it is not a good idea to submit OG work to the commercial printing industry. So many variables, problems, glitches, and bugs exist that it is a small miracle when problems don't occur. Simply writing "OG files supplied..." in the specification does not mitigate the fact that OG applications are very challenging to GPO vendors and almost always result in costly contract modifications. The essential question that customers must ask is this: "Is it worth the extra money and aggravation to send in OG files?" and "Is it acceptable to shoot camera copy?"

OG software should not be used to create products that are being or will be produced on conventional or high-end digital printing equipment. OG software makes no provision for even the most basic prepress functions such as color separations, trapping, or bleeds. These packages also fail to provide appropriate font and graphics handling capabilities and were not created as professional print publishing design tools. GPO specialists should realize, however, that due to a variety of factors, avoiding OG applications is not always realistic. Customers who supply print publishing files created using OG software should expect any print vendor to experience output problems. In many cases "fixing" the problem requires some of the extraordinary measures discussed in this article or it requires a vendor to recreate the entire publication (including graphics), which is both time consuming and costly. Save yourself time, save yourself money, save yourself sanity! Put that OG stuff back on the shelf and put down the money up-front for professional publishing software. Spend a little now, or most assuredly pay more later.

 

 

 

 

This article pertains to:



 

 

 

 

 

 

 

 








 

 

 

 

 

 

 

 

 

 

 

 

 

 

 




 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


ePUB home
Ask ePUB
Return to cover
GPO home