Because of the wide usage of direct-to-plate workflows, few printing companies are still outputting and manually stripping film, although I suppose it may be going on in the hinterlands. The only exception would be specialized printing processes, such as screen printing or metal etching. While registration marks and other locating marks are used on press to monitor ink alignment, those marks are usually generated by the imposition software that positions the pages for output, rather than the original page layout or illustration applications.

What color, exactly, is Registration? It’s all the inks used in the document: it’s 100% of all inks. So, in a job containing CMYK plus PMS 185, Registration would be C100-M100-Y100-K100 plus 100% PMS 185. This adds up to a whopping 500% ink coverage where Registration is used. This is not a press problem in isolated areas such as trim and registration marks, but such heavy ink coverage in larger areas would result in drying issues and other problems. And if there’s slight misregistration on press, you’ll get a bleary multicolored fringe:

This is exaggerated for dramatic effect, but it's still possible for thin fringes of color to spoil the look of the printed piece.

=================================

Why do I bring this up? Because twice this week I encountered files built with Registration instead of plain old Black. If there had been just one element — say, a line of text — using Registration, I would have chalked it up to mis-clicking: aiming for Black, and accidentally hitting the next color in the list. But, no: in both cases, Registration had been used for all the text in the InDesign page, as well as artwork created in Illustrator. Clearly, it was intentional. But why?

My guess is that the designer thought plain old Black just wasn’t robust enough; maybe it looked anemic on their desktop printer. And it’s true that process black ink alone in large areas can look, well, gray rather than black: that’s why we use rich black builds in large areas. Registration is not an appropriate “rich black,” however!

If your design contains large bold black text (40 pt or above), or large solid black areas, consider using a rich black build (try C40-K100). Better yet, ask your printer what they’d recommend for a rich black recipe, as well as their advice on where to use it (i.e., text size or color area dimension).

I wish the applications wouldn’t even display Registration; maybe it should be a hidden color choice, available only from a subsidiary panel menu in the Swatches and Color panels. Until then, you’ll have to police yourself: don’t click there!

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.]