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
poppler :-(
-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,
Thomas
Albert
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
[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
