Number 207 - August 2000

The Service Bureau Shuffle
Rick Altman's Col. in Sacaramento May 2000 Sacra Blue This article originally appeared in Publish magazine (www.publish.com)
Yes, you can send your PC-formatted files to a Mac-based service bureau     The five most loathed words that a Windows-based graphic artist or publisher ever hears? That's easy, it happens at the end of a project, not at the beginning. It happens after all of the inspiration and perspiration of completing the job. It happens when it's time to have the work imaged at the local service bureau (SB).     "Oh, that's a PC file"     These five words are typically followed by an equally-disquieting remark about how they'll do their best, or they can't guarantee anything, or they'll get some image out, but...     Almost 15 years into the era of desktop publishing, the notion that you use your PC to create the work and they use their Macs to image it still doesn't vibrate at quite the right frequency. And the fact that this is changing for the better--that PC-based service bureaus are beginning to surface across the country--does not change the basic axiom: If you plan to publish professionally, you must ensure peaceful relations with Mac-based service bureaus. You...not them. The responsibility is yours. You are the minority; you must take matters into your own hands. For most jobs, this involves knowing your Fs and Cs: Format, Font, Color, and Communication. How do I Save Thee?     Would that you could simply issue a Save As command to your Zip drive and send the disk off. You probably can't. Unless you have thoroughly tested and established that the operators at your SB can accept your native application files, there is too much risk involved. Do they have the same version and the same revision level? Do they have the same typefaces? Is color management in sync? Do they know the program? You give up quite a bit of control when you send native files to your SB; that requires extraordinary trust.     On the other side of the spectrum, there remains little to recommend sending PostScript print files. Once the only way to send your project to a remote SB, now it is anachronistic. Complete accountability for the job lies with you, and while there is an admirable component to that, it is not realistic. When you create a print file for remote output, you are essentially pretending that you own the printer. You are expected to know everything about a printer that you perhaps have never even seen before. Furthermore, you leave the SB operators completely in the dark, delivering to them a morass of PostScript code. If the slightest thing goes wrong, not only will they not know about it, but there won't be a darn thing they can do about it. For that matter, many SBs do not even know what to do with a print file--they can't simply open it up in a standard application and print it.     The two more viable file format choices allow you to keep control of the project and at the same time allow SB operators to get involved. The one with the most momentum and promise is Adobe's Portable Document Format (PDF). When you create a PDF file, you do three very important things: 1) You gather all of the PostScript data necessary to describe your project; 2) You wrap it up in a format that can be viewed on-screen; and 3) You deliver it in a package that can be easily opened, inspected, proofed (even corrected in some cases), and then printed by your SB operators. They make sure that the printer configuration is correct; not you. You supply the image of your project, they supply the info about printing it--that's good teamwork.     Furthermore, your SB can open a PDF file and print portions of a job, if necessary. So a corrupted page 241 won't scuttle the printing of an entire book, and you can simply correct and resupply that one page.     If you do not own Adobe Acrobat, then the best advice this column can offer is for you to acquire a copy of it. But whatever you do, do not rely on an application's promise to create PDF files without Acrobat. Unless you use version 9 of CorelDRAW (the one program that does support professional-level PDF-creation without Acrobat), you will likely be working with a cheap PDF writing tool that was intended for creating low-res proofs, results from which would be barely better than using a screen capture program. While your intention would be to use the best possible method of delivering your files, you would actually be using the worst conceivable one.     The other format that produces good results, especially for jobs of few pages, is an encapsulated PostScript (EPS) file. Like PDF, an EPS file contains all of the essential PostScript data to output your project, but it is designed to be placed into another file, not sent directly to a printer.     Most programs create EPS files from their Export commands, not their print commands, and you would create one file for each page in your project. Typically, SB operators will import an EPS file into QuarkXpress or Adobe PageMaker and then print it from there. Printing from Xpress might seem like heresy to a self-	respecting Adobe or Corel user, but in fact, the arrangement is a smart one: You use the program you are most comfortable with for creation, while the SB uses the program its staff is most comfortable with for printing. And as with PDF, you leave all of the print configuration requirements up to the SB. Don't Play the Font Follies     When you stay within the comfortable confines of Windows, you can choose your typefaces as good taste permits. But when you are heading over the bridge, you introduce another constraint, as Macintosh equipment has a history of trouble with TrueType format typefaces. PC loyalists claim the Mac is brain-dead; Mac zealots argue that it is the Windows-centric typeface format that is flawed. No matter who is right, your best bet for work destined for an SB is to confine yourself to typefaces that conform to Adobe's Type 1 format (referred to interchangeably as Type 1 or PostScript faces).     Most users of Adobe software have a library of Type 1 faces, so this is not likely to be an issue. And while they may not know it, Corel users do, too. The standard installation speaks only of TrueType faces, but all 1,200 typefaces that come with CorelDRAW are also available in Type 1 format. They remain buried in a subfolder on the CD and you will have to install them yourself. If you are used to using TrueType faces with your Windows applications, learning about Type 1 will be time well spent. Use Type 1 faces for your SB work, and you will reduce by one the things that can go wrong. Color Me...Correctly     The final ignominy that could await you, the unsuspecting PC publisher, are colors that are so far removed from what you had intended as to be hazardous to your career. This is the all-too-familiar result of using photographs or other graphics that were born on the PC and therefore speak its native language of RGB color. Red, green, and blue...the three colors that are responsible for visible light. Unfortunately, they have little to do with how printed inks depict wordly (sic...worldly?) items.     If your work is destined for a press that uses printed inks--spot or process--it is imperative that you use the same color model when creating your images and your objects. You must convert scanned photographs from RGB to CMYK (or duotone), you must fill objects with colors from process or Pantone color palettes, and above all, you must never choose colors from on-screen palettes just because you think they look pretty on your monitor. Always choose colors from printed samples, like swatch books or work you have already printed successfully. You also must make sure that your color management system is calibrated for the type of printer your SB will use, and if that sounds like so much mumbo-jumbo, your SB can fill in the gaps and probably even supply you with a color profile on disk.     The need to stay in the CMYK space is not news for many of you, but a handful of you will be unpleasantly surprised to discover that your software might be speaking RGB behind your back. CorelDRAW boasts some of the most impressive transparency and shadowing of any vector-based program, but older versions of the software did so by creating RGB bitmaps. Most of the Microsoft applications shoot RGB first and ask questions later, as well. Talk to Them!     Your service bureau operators might prefer Macs, but they won't bite! Ask them what their experience is with PC applications, find out what has worked for them in the past, sound them out on using PDF files. Above all, ask them if they'll be agreeable to a few experiments. Most will, and many won't charge you for the film. After all, they are as motivated as you to make the PC-to-Mac bridge a steady one; they stand to gain considerable business from an untapped sector of the marketplace.     Send them a small project several different ways. PDF...EPS... native format...all text as Type 1...some text using a favorite TrueType font...all bitmaps as CMYK...the same images as RGB...special effects left in their original state...the same effects separated and converted to CMYK. Not to get too melodramatic, but this is no different than other relationships you maintain--it requires good communication.     The rewards are plenty for this effort. First and foremost, your work will not suffer just because you have to work with a service bureau that uses a different platform. And in the long run, you will be doing your part to break through a decade-old stigma. With your help, service bureaus will begin to adopt a different tone when greeting you and your colleagues:     "Oh, a PC file? No problem, here's what we'll do..."     Did you know that Corel maintains an active list of service bureaus that have earned the status as a Corel Authorized Service Bureau? You can get more information from the CASB pages on Corel's Web site at www.corel.com/partners_developers/casb/serviceb/" target="_blank
Number 207 - August 2000