A follow-up on my post

Hi everyone, and thanks to those of you who made suggestions to  
explain my problem with Rich Black in my PDF and resulting printing.

I spent 45 minutes on the phone with Dov Isaacs at Adobe yesterday,  
and he helped me to understand why this is happening.

Here is the text of my blog on Graphic Arts Monthly yesterday, which  
describes the problem and the solution.

I cannot include the illustrations here, but if you want to see them,  
please go to http://www.graphicartsonline.com/blog/1860000386.html

Again, thank you all for your thoughtful responses to my question.

Brian P. Lawler
San Luis Obispo, California



Simulating the press, part IV

July 27, 2009 The process of preparing artwork for print has created  
the opportunity for a number of pitfalls. The world is not as simple a  
place as one might imagine, and images, text and graphics do not alway  
come in one color space and from one color source.

In the on-going project of printing the Visitors Guide, I have been  
involved in every step of the color management and prepress, and now  
the press checks. I can tell you that none of this is routine for me.  
Ironically, though, it is what drives the printing industry day-in and  
day-out. I am just not in the pressroom that often as “customer,” so  
this has been a great experience for me.

The ink-jet proof I hoped to get was impossible because the ink-jet  
machine can’t be driven by the printer’s RIP at the moment. The ink- 
jet printer, a new Epson 9800, requires an upgrade to a newer version  
of the work flow software, and that upgrade is not yet installed on  
the printer’s equipment. So, instead of making an ink-jet proof, the  
printer chose to make a proof using a Xerox 700 digital press driven  
by a Spire RIP from Kodak. In order to do this, he first used the  
Spire’s built-in color calibration software, and then he built an ICC  
profile of the Xerox system using ProfileMaker Pro and an iOne Pro  
spectrophotometer.

The Spire allows for the loading of the device calibration, and also  
allows for a press simulation profile to be added. So, my proof was  
made on a machine that is calibrated, which then was behaving like the  
MAN Roland 40-inch press just around the corner. With the simulation  
profile in place, the very large color gamut of the Xerox toner-based  
printer is attenuated to behave more like a press.

Despite the quality of the calibration and the profile, though, the  
Xerox proof was slightly too strong in magenta. By a series of  
iterative steps (science-talk for trial and error), the printer and I  
were able to “dial-in” the profile for the Xerox device to the point  
where it produced very, very close proofs for the press. To do this,  
we used Profile Editor, and we reduced the magenta in the Curves  
control until it matched the press.

The printer made a complete, imposed booklet of the Visitors Guide to  
show to the client, and, after their approval of that proof, we set  
about getting the cover printed.

The cover was set-up as an eight-page work-and-turn on a stock that is  
heavier than the body of the Visitors Guide, so that was run first.  
The cover, and the three pages of advertising that accompany it, have  
very little text that prints in black only, so we did not notice that  
the black text was printing in CMYK (and it doesn’t harm the job, as  
it was printed in perfect register). But, when the first form of the  
interior pages (8-pages sheetwise) went on-press, the pressman noticed  
immediately that small text that should have been 100% black – only –  
was printing as a combination of CMYK in various percentages (see the  
Acrobat palettes, below). So he stopped the press.


[Screen shots go here]


Here is the problem: In the image on the left, the Simulation profile  
set in Acrobat does not match the profile used to create the PDF  
document, and blacks are being reinterpreted to 89,78,82,77, which  
creates an impossible situation on press. When the profile is set  
correctly, right, the black text is only black at 100%, and this is  
correct. The palette is called Output Simulation, under Print  
Production in Acrobat Pro.

I arrived shortly after that decision, and was both surprised and  
disappointed by the situation. The designer and I had worked to build  
the PDF correctly, using the press profile that I had built, and  
“preserving numbers” in the CMYK to prevent native InDesign text and  
other solid blacks from being converted to something different. But,  
here I was, standing at the press control table looking at a whole  
bunch of CMYK black and a scattering of noise dots around the  
lettering. Something was amiss.

I raced back to the designer’s office and we tested the process. A  
curious thing was occurring: when we embedded the destination profile  
in the PDF, it created “rich” black – lettering and other art that  
should have been 100%K. When we did not embed the profile in the PDF,  
the text came out 100%K only, which is what the designer wanted.

So, we recreated the entire booklet, making sure not to embed the  
destination profile.

That profile is unnecessary, as the conversion to CMYK is complete  
whether it’s embedded or not. But, embedding it (I have learned since)  
causes ICC profile “tags” to be added to every object in the PDF  
document. And, that is where our problem was rooted.

When our printer gets the PDF, and forwards the pages to his RIP, he  
exports EPS files from the PDF file. In the Export function in  
Acrobat, color management is performed as the EPS documents are being  
created. And, if the CMYK profile that is embedded is not also set  
under “Settings” in the Export window (they must match), then the CMYK  
color that is in the PDF, and tagged with a specific CMYK profile,  
will be converted to whatever CMYK profile is set in the prepress  
operator’s machine (usually SWOP Coated), and the color will all be  
converted from CMYK in the PDF to a new CMYK generated by the profile  
on the system doing the conversion. This, of course, is all wrong.

If the prepress operator recognizes the problem, then he or she can  
match the outgoing CMYK profile with the embedded profile, and nothing  
will be changed in the file. This would be good.

And, similarly, if the CMYK in the PDF is not tagged (no destination  
profile was embedded in the PDF), then the color will be processed by  
the EPS Export function in Acrobat without converting CMYK to CMYK,  
saving the job.

This is seemingly illogical, but it does work correctly when all the  
steps are controlled with care.

More tomorrow, or maybe later tonight! We’re in the thick of things  
today, with numerous press checks and press runs. It’s turning out  
well, now that we have discovered the error of our ways in the work  
flow.

(Thanks to Adobe’s Dov Isaacs for the explanation of the process of  
exporting EPS from Acrobat.)

Posted by Brian Lawler on July 27, 2009  
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list      (Colorsync-users@xxxxxxxxxxxxxxx)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/colorsync-users/maillists%40codeha.us

This email sent to maillists@xxxxxxxxx