[poppler] Implementing overprint in Splash

[Thomas Freitag]

On 25.03.2011 20:07, Albert Astals Cid wrote:
> A Dijous, 24 de març de 2011, Thomas Freitag va escriure:
>> 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 :-(
> There is copy in Splash using the error() function already, so it's nothing
> new :D
Ok. I don't like it, but it's up to You. I'll change it,
>>>> -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.
> So we add an option that does nothing (to the end user, that's it)? I'd prefer
> that not to happen.
Ok. I'll upload a complete patch when finishing. My laptop has still not 
finished creating the differences (in rendering) with the complete 
patch. Be happy then to find out the differences by Yourself :-)

(Sorry, I wasn't be able to stop myself :-) )

Thomas
> Albert
>
>> 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
>>>>>> 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
>>>>>
>>>>> .
>>> _______________________________________________
>>> 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
> _______________________________________________
> poppler mailing list
> poppler at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/poppler
>
> .
>