[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