Sections 8.6.7 and 11.7.4 of ISO 32000-1:2008 should give you a lot of information. There is also some great text in the current draft of 32000-2, but that's not public at this time. FYI: 11.7.4, handling overprinting and transparency together, is a LOT of work - and you probably shouldn't try to handle that one till you get non-transparency working.
As for being deep in this - I certainly hope so, it's my job :). Leonard Rosenthol | PDF Architect · Principal Scientist | Adobe Systems | [email protected] -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Thomas Freitag Sent: Monday, March 21, 2011 1:23 PM To: [email protected] Subject: Re: [poppler] Implementing overprint in Splash 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? Thomas > > > Leonard > > -----Original Message----- > From: Thomas Freitag [mailto:[email protected]] > Sent: Monday, March 21, 2011 9:09 AM > To: Leonard Rosenthol > Cc: [email protected] > 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: [email protected] >> [mailto:[email protected]] On Behalf >> Of Thomas Freitag >> Sent: Monday, March 21, 2011 1:59 AM >> To: [email protected] >> 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 >> [email protected] >> http://lists.freedesktop.org/mailman/listinfo/poppler >> >> . >> > > _______________________________________________ > poppler mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/poppler > > . > _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
