Claudia McCue

It was another one of those thoroughly snakebit jobs that go wrong at every step, but at its core is a mystery concerning how QuarkXPress treats an overprinting grayscale image in an exported PDF. “Regular” overprinting objects, such as text or boxes, display and print predictably. But grayscale images are handled differently, and this results in a misleading display in Acrobat, which leads to a surprise on press. And, as you know, “surprise” is not a good word in printing.

Here’s the timeline:

• Customer sets a grayscale image to overprint in QuarkXPress 7. Why, I have no idea. What makes this particularly messy is that the image falls on top of a rich black — nay, an opulent black — background of C40-M20-Y20-K100.

• Customer submits job via printer’s online submission service, which is a combination of Creo Prinergy and some proprietary components. Customer previews PDF onscreen in Acrobat, and everything looks hunky-dory (Latin for “no overprint”). This is what the customer sees, even with Overprint Preview turned on in Acrobat:

(Above: This is not the original job; it’s my replication
of the issue. The image on the left is NOT set to overprint.
The image on the right IS set to overprint. Yes, I know
you can’t tell that from this image: this is how it displays
in Acrobat, even with Overprint Preview turned on.
That’s the whole point of this post: the file displays
incorrectly in Acrobat, as you’ll see shortly.)

• Because the printer’s workflow is intended to be fairly automated (and Acrobat’s display is deemed reliable), the customer’s OK sends the PDF into the job queue.

• Like a log floating downstream, the PDF flows through RIPping, proofing, and on to platemaking.

• The job plates and prints, and to the customer’s horror, the printed piece differs significantly from their concept and the Acrobat soft proof:

(Above: Oops. This is how it printed. Pretty, but not
what they had in mind. Despite Acrobat’s display,
the image does carry “please overprint me” information,
and that instruction is exercised when the job is processed.
And printed. Yikes.)

I have no idea why Acrobat refused to display the image as overprinting. If asked to highlight overprinting objects, Acrobat cheerfully highlights the area of the offending image. But it will not display its multicolored appearance correctly, and even the “rolling densitometer” within Acrobat’s Output Preview lies: it shows only process black in the area of the overprinting image.

But it gets weirder. This is a fully legitimate PDF/X-1a file, exported from QuarkXPress 7. Acrobat validates it as PDF/X-1a. It doesn’t get any better than that, folks. If I place the PDF into InDesign, InDesign‘s Overprint Preview tells the truth: the background shines through the image, and InDesign’s Separation Preview gives correct readouts of the CMYK values in the image (C40-M20-Y20 plus whatever’s in the image). If I open the PDF in Illustrator (just as a science project, mind you), Illustrator‘s Overprint Preview and Separation Preview both tell the true story. And if I generate separated PostScript from Acrobat and Distill it, the separated file correctly shows the overprint behavior, so clearly Acrobat knew it on some level. Aaarghh! Oddly, if the image overprints a spot color, Acrobat does display that correctly. It’s just where the grayscale image overprints the rich black, or any other process build.

So why doesn’t Acrobat show (or tell) the truth? Beats me. I’ve sent example files to my friend and Acrobat gymnast extraordinaire Leonard Rosenthol to see if he can un-knot the mystery. I’ll let you know if he comes up with an explanation.

It’s important to note that only grayscale images seem to cause this strangeness in QuarkXPress. As I remarked above, text and page geometry set to overprint will display correctly in an exported PDF. And such arrangements created in InDesign or Illustrator do display correctly in Acrobat.

In the mean time, what’s the lesson here? As often happens, there’s more than one:

1. Don’t set images to overprint unless you intend to create a special effect.
2. Insist on hard-copy proofs from the printer. If they don’t look right, hit the brakes on the job. Don’t assume it’ll heal up on the way to the press. And if the printed piece differs from the contract proof, it’s up to the printer to fix it and reprint, or pay a penalty, IMHO. That’s why they call it “contract proof.”
3. If you’re the pressman, and the printed sheet doesn’t look like the hardcopy or onscreen proof, consider that this might constitute a huge, press-stopping problem.

NOTE: This circumstance — a black-only image overprinting a CMYK mix — is odd conceptually. Where the black image overprints the black plate of the background, the software decides that the image predominates, and doesn’t “add” the black values of the image to the black values of the background (or the area would be 100% K). I suppose this is because an ink can’t overprint itself (well, not without time travel).

Have a headache yet? I certainly do. And now I’ve given it to someone else; I’m sorry, Leonard.

[Later note: This has now been logged as a bug in Acrobat, so Adobe is aware of it. So perhaps it will be fixed in a future version. In the mean time, just remember it, and use all of Acrobat's forensic tools to find the scary stuff.]

Trackback URI | Comments RSS