[poppler] Implementing overprint in Splash

Thomas Freitag Thomas.Freitag at kabelmail.de
Thu Mar 24 01:12:10 PDT 2011


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

Thomas

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 :-)
>
> Albert
>
>> 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
>
> .
>

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pdftoppm.patch
URL: <http://lists.freedesktop.org/archives/poppler/attachments/20110324/b0845deb/attachment.ksh>


More information about the poppler mailing list