Hamilton--An Issue of Compatibility
September 2000
|
Perhaps the most incredible thing about the printing industry is that it actually works. Most of the time, anyway. Think about it: You have a sophisticated manufacturing process driven by people hired specifically for their creative expertise.
Adding to the confusion, the disparate nature of this service industry makes it virtually impossible to standardize procedures—which is why workflow is such a vague term. In many cases, designers, ad agencies, publishers, prepress trade shops and printers are all separate business entities; at a minimum, there are two parties: content creator and prepress/printer. And, just for fun, there's the subjective nature of the printed product itself adding to the confusion.
As for me, I've always wondered what people are talking about when they say the image needs more "pop" or ask the press operator to "bring up the reds." Is that like raising children as communists?
At issue here is customer training and education. Frankly, it's hard enough to master all of the necessary desktop publishing software programs, even for narrowly defined tasks. Furthermore, this is becoming more complex as vendors such as Adobe and Quark try to increase the versatility—and sell upgrades to a saturated market—by adding tools to programs like Photoshop and QuarkXPress. With designing for the Web pulling graphic artists in totally new directions, as well as a different color space, it's no wonder that supplied files continue to make prepress technicians pull their hair out.
Recently, this issue came into focus on one of the industry bulletin boards. Although the particular beef was over color management, this type of problem has been around since "RageMaker" came onto the market in the mid-'80s. In this particular instance, the printer had spent hours optimizing images for particular output conditions—in this case CMYK—and then sent them to the client for cropping and other minor adjustments. When the files came back, they were in a different color space (RGB) and all the printer's efforts were for naught.
In the ensuing posts, the issue of responsibility came up in a number of guises. Was this the fault of Adobe, for embedding color management utilities in Photoshop? The designer/client for misusing it? Or the printer for not educating or warning the client about the files and their device dependence? In my mind, the printer was guilty only of not making backups of the files. The rest of the problem is one that goes far beyond color spaces and device dependence.
Adding to the confusion, the disparate nature of this service industry makes it virtually impossible to standardize procedures—which is why workflow is such a vague term. In many cases, designers, ad agencies, publishers, prepress trade shops and printers are all separate business entities; at a minimum, there are two parties: content creator and prepress/printer. And, just for fun, there's the subjective nature of the printed product itself adding to the confusion.
As for me, I've always wondered what people are talking about when they say the image needs more "pop" or ask the press operator to "bring up the reds." Is that like raising children as communists?
At issue here is customer training and education. Frankly, it's hard enough to master all of the necessary desktop publishing software programs, even for narrowly defined tasks. Furthermore, this is becoming more complex as vendors such as Adobe and Quark try to increase the versatility—and sell upgrades to a saturated market—by adding tools to programs like Photoshop and QuarkXPress. With designing for the Web pulling graphic artists in totally new directions, as well as a different color space, it's no wonder that supplied files continue to make prepress technicians pull their hair out.
Recently, this issue came into focus on one of the industry bulletin boards. Although the particular beef was over color management, this type of problem has been around since "RageMaker" came onto the market in the mid-'80s. In this particular instance, the printer had spent hours optimizing images for particular output conditions—in this case CMYK—and then sent them to the client for cropping and other minor adjustments. When the files came back, they were in a different color space (RGB) and all the printer's efforts were for naught.
In the ensuing posts, the issue of responsibility came up in a number of guises. Was this the fault of Adobe, for embedding color management utilities in Photoshop? The designer/client for misusing it? Or the printer for not educating or warning the client about the files and their device dependence? In my mind, the printer was guilty only of not making backups of the files. The rest of the problem is one that goes far beyond color spaces and device dependence.
Companies Mentioned:
 |
|
|
Print Production Workflow: A Practical Guide
The Ultimate Guide to Multi-Channel Communications Solutions
