[Gs-devel] PDF overprint mode, transfer functions

[Raph Levien]

In talking with Dan about implementing overprinting (generally as part
of the DeviceN project), we got to an ambiguity in the PDF spec,
namely the interaction between overprint mode and transfer functions.
I decided to do a little testing to find out, at least, what Adobe PDF
implementations do about this.

My test file is at: http://www.levien.com/pdf/op-tr.pdf

To refresh people's memory, when OPM is 1, a "tint value" of 0.0 for a
source color component leaves that plane unchanged. This lets you do
overprinting effects without setting up new color spaces.

The exact concept of "tint value" is not fully defined, however. In
particular, when a transfer function (TR) is in effect, does "tint
value" refer to the original values in the file, or to the values
after transformation? The latter would be a bit easier to implement
in the current GS framework.

I tested the file on three Adobe PDF implemenations: Reader 4.0 for
Linux, Acrobat 5 for Windows, and Adobe Illustrator 9 for Windows.
Here are the results:

Reader 4.0 seems to ignore the overprint setting altogether. The
first and second samples look identical (both rendered opaquely).
The third sample suggests strongly that the CMYK->RGB conversion
is happening before the transfer function is applied.

Acrobat 5.0 has an "overprint preview" mode. In this mode, the second
sample is rendered with the overprinting. The third sample is
identical to the second. This strongly suggests that the TR is applied
before the comparison for 0.0 is performed for overprinting purposes.

Acrobat 5.0 without "overprint preview" behaves logically the same
as Reader 4.0 for Linux, but the CMYK->RGB transform itself appears
different (in particular, combinations of black and two other
process colors appear solid black in Reader, but merely dark in
Acrobat). God help anyone who's trying to use Acrobat as a "soft
proof" in color-critical environments.

Adobe Illustrator 9.0 deals with this problem in another way
altogether: by ignoring the TR setting in the graphics state. Thus,
the first two samples render basically the same as in Acrobat, but
the third becomes all black.

GS fails to load the file, with a PostScript error on the third
sample. I'm not sure whether this is a bug in GS, or an infelicity
in my hand-built PDF file. I'm not all that inclined to follow up
at this point - if there's a real bug, it should show up in our
support flow.

I am soon going to start a "Commentary on the PDF specification"
document, intended to illuminate bugs, ambiguities, compatibility
issues, and underspecification of the PDF spec. This note will
become a section in that document.

Summary: I believe it is safe to implement OPM at a low level, on
pixels that have already been transformed. Applications which depend
on a particular handling of TR do so at their own risk, as it seems
to vary considerably between Adobe implementations of PDF.

Raph