[poppler] Implementing overprint in Splash

Thomas Freitag Thomas.Freitag at kabelmail.de
Mon Mar 21 13:22:52 PDT 2011

Am 21.03.2011 17:16, schrieb Leonard Rosenthol:
>> any source color already converted to CMYK
> And THAT is the problem!
> If the original colorspace is NOT CMYK, then the rules for overprint are either different (eg. Gray) or don't apply (eg. RGB).  You NEED to know the original colorspace in order to determine what do - you can't simply rely on the OP-related flags.  This is especially true in files that register a "false positive" for OP - a common occurrence from files produced with Quark.
Any more hints, Leonard? I think, it is not a great problem to switch of 
overprint in case of RGB, ot behave different in case of Gray (how???). 
Is there any understandable paper which I can read? What do You mean 
with "false positive"?
> This is especially true for Separation and DeviceN colorspaces.  You will also need to, in order to properly support these two, implement support for the named colors rather than entirely relying on the alternate color.
It seems that You are really deep into this! Can You share Your knowledge?

> Leonard
> -----Original Message-----
> From: Thomas Freitag [mailto:Thomas.Freitag at kabelmail.de]
> Sent: Monday, March 21, 2011 9:09 AM
> To: Leonard Rosenthol
> Cc: poppler at lists.freedesktop.org
> Subject: Re: [poppler] Implementing overprint in Splash
> Hi Leonard!
> First, thank You for Your response.
> Am 21.03.2011 14:10, schrieb Leonard Rosenthol:
>> First, let me say that having more PDF renderers support Overprint Preview (since it's really a simulation and not the real thing) will be GREAT!  Especially so in light of the "conforming reader" requirements in ISO 32000-2 that are forthcoming.
>> Now, that said, I think you may be simplifying things for #3 - the actual implementation.  It's not as simple as modifying the code that puts the CMYK "bits" down (based on the OP/OPM values) BECAUSE of the way that Poppler's colorspaces work.  You will actually need (IIRC) to do a bunch of work in there in order to handle the differences for Separation and DeviceN colorants (and DeviceN will be the most tricky to get correct).
> Yes, I propably simplified. Unnecessary to say, that it is really easy
> to put the overprint values on the splash state stack, so we have it
> everywhere where it is needed. And I found the central place, where
> blending and computing the result pixel values is done. BUT: when we
> expect we are in splashCMYK8, I have at this central place any source
> color already converted to CMYK, and the destination color in CMYK. So
> what I mean it is here quite easy to implement overprint. If the
> painting colorspace is any other the Separation or DeviceN, I can easily
> implement table 148 and 149 from ISO 32000-1. Unfortunately, what has to
> be done when it is Separation or DeviceN, it is not really clear for me.
> I thought, if I have there CMYK values I could handle them as if they
> CMYK values from a DeviceCMYK. I made some tests with PDFs claimed to be
> in DeviceN and use overprint, and the result seems to be simular to what
> Acrobat Reader shows...
> I also found no samples in ISO 32000-1 ( seems to be it has samples for
> nearly everything, but not for overprinting :-) ). So any help, hints to
> other documents which could clearify it for me are appreciated.
> But nevertheless, Your answer makes implementing overprinting for me
> even more interesting :-)
>> It's clearly doable, but it's not going to be trivial...
>> Also, I STRONGLY recommend that Poppler do the same thing that Adobe Acrobat/Reader does and which is now (partially) codified in the forthcoming ISO 32000-2....If you detect that the PDF claims compliance with one of the PDF/X standards, you should ALWAYS render with Overprint Preview enabled.
> Okay, but because in poppler You have to specify the output colorspace
> BEFORE starting render the page, and overprinting will be implemented
> only in splashCMYK8, it would be up to the application which uses
> poppler to detect that overprinting is used and use splashCMYK8 then.
> Thomas
>> Leonard
>> -----Original Message-----
>> From: poppler-bounces+leonardr=adobe.com at lists.freedesktop.org [mailto:poppler-bounces+leonardr=adobe.com at lists.freedesktop.org] On Behalf Of Thomas Freitag
>> Sent: Monday, March 21, 2011 1:59 AM
>> To: poppler at lists.freedesktop.org
>> Subject: [poppler] Implementing overprint in Splash
>> Hi all!
>> After being quite close with my last bigger poppler project I now think
>> about implementing overprinting in Splash.
>> 1. What is overprinting?
>> For those who don't know what is overprinting, please refer to
>> http://en.wikipedia.org/wiki/Overprinting. This is just a poor
>> description, what overprinting is. Who need to know more about it,
>> please read
>> http://www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/PDF32000_2008.pdf,
>> chapter 8.6.7.
>> 2. Actual state of overprinting in poppler.
>> Overprinting is implemented in Gfx, only missing the parameter overprint
>> mode, but the only output device which supports it in the moment, is
>> PSOutputDev. But even there probably the most people haven't encountered
>> that really: If You render the PostScript produced with PSOutputDev with
>> ghostscript, it is normally rendered in RGB, an additive colorspace. And
>> because overprinting is normally specified only in subtractive
>> colorspaces like CMYK, You have to specify a cmyk device like tiff32nc
>> to see the effects of overprinting.
>> 3. Implementing overprint in Splash
>> It is quite easy to implement overprinting in Splash. Splash supports
>> CMYK output with the compiler switch SPLASH_CMYK. But as in PSOutputDev
>> I fear, that only a few people use it. And the mainly used program
>> pdftoppm doesn't support CMYK output. And now we are coming to the main
>> point why I write this email:
>> 4. Support of overprint in pdftoppm
>> To support overprint in pdftoppm we have to enable SPLASH_CMYK in
>> pdftoppm and use it for rendering. But all output formats defined in
>> pdftoppm uses RGB as output colorspace, and even the main output formats
>> ppm and png do not support CMYK colorspace. Therefore we have to
>> possibilities to support overprinting in pdftoppm:
>> a) The easiest way would be to specify a new output format like i.e.
>> jpegcmyk and create a jpeg image in CMYK colorspace where overprinting
>> will be supported.
>> b) The more interesting way is to add a new parameter -overprint, when
>> set use splashCMYK8 as colorMode and when writing the output file
>> convert it to RGB. The first implementation could use the poor
>> colorspace conversion in Splash to convert the CMYK bitmap to RGB, but
>> we should think of use little cms to do that work for us, which of
>> course means that compiling pdftoppm will become more complex.
>> Any suggestions from the community to point 4?
>> Thomas
>> _______________________________________________
>> poppler mailing list
>> poppler at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/poppler
>> .
> _______________________________________________
> poppler mailing list
> poppler at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/poppler
> .

More information about the poppler mailing list