[poppler] Implementing overprint in Splash
Thomas.Freitag at kabelmail.de
Thu Mar 24 13:47:17 PDT 2011
On 24.03.2011 21:14, Albert Astals Cid wrote:
> A Dijous, 24 de març de 2011, Thomas Freitag va escriure:
>> I don't know if this patch is useful without the outstanding overprint
>> patch for Splash, but I finished implementation of the two new options:
>> -overprint renders the PDF in in splashCMYK8 first and converts the CMYK
>> Splash bitmap to RGB during writing (compiler switch SPLASH_CMYK must be
>> set on pdftoppm and on poppler library). It's implemented for png, jpeg
>> and tiff, tested for png and jpeg but should work with tiff, too.
>> USE_CMS is not implemented in the moment, the conversion from CMYK to
>> RGB is done with a copy from the GfxState-routines.
> Why copy the functions?
There are "static inline" in the Gfx header files. I could include the
header file in Splash, but that means that we begin to mix splash and
>> -jpegcmyk produces a jpg in CMYK colorspace (compiler switch SPLASH_CMYK
>> must be set on pdftoppm and on poppler library).
>> Because overprint is not implemented yet, the overprint option changes
>> nothing in the moment. So this option can be used as a zero state for
>> overprinting to see which PDF renders differently with the outstanding
>> first implementation of overprinting.
> Don't understand this.
-overprint option(!) simply renders in splashModeCMYK8 and during
writing it is converted to RGB, so the better option would probably be
to render it directly in splashModeRGB8. But overprint functionality(!)
is naturally only defined in a CMYK colorSpace, therefore we need
splashModeCMYK8 for the overprint functionality. But because overprint
(functionality) is not really implemented in splash with this patch, the
output should nearly the same (nearly, because without the option we
directly render in RGB, with the option we render in CMYK and convert
CMYK to RGB afterwards).
What I mean with zero state: I just run the create MD5 script with this
patch to have an initial MD5 value, assuming, that the output is correct
(because nothing is really changed in the underlying functions).
Tomorrow I'll run my roughly tested overprint patch against this and
examine, what pdf have changed. If these changes fit to specifications,
I'll upload the overprint patch to the community.
Hope, this clearifies it,
>> Am 21.03.2011 20:47, schrieb Albert Astals Cid:
>>> A Dilluns, 21 de març de 2011, Thomas Freitag va escriure:
>>>> Hi all!
>>>> 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?
>>> Both seem interesting :-)
>>>> poppler mailing list
>>>> poppler at lists.freedesktop.org
>>> poppler mailing list
>>> poppler at lists.freedesktop.org
> poppler mailing list
> poppler at lists.freedesktop.org
More information about the poppler