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