[poppler] Implement overprint in qt interface?

Tue Oct 23 00:25:29 PDT 2012

Am 23.10.2012 06:51, schrieb Adam Reichold:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> On 23.10.2012 00:56, Albert Astals Cid wrote:
>> El Dissabte, 20 d'octubre de 2012, a les 17:36:22, Thomas Freitag
>> va escriure:
>>> On 16.10.2012 22:57, Albert Astals Cid wrote:
>>>> El Dilluns, 15 d'octubre de 2012, a les 07:15:51, Thomas
>>>> Freitag va
>> escriure:
>>>>> On 14.10.2012 22:58, Albert Astals Cid wrote:
>>>>>> El Diumenge, 14 d'octubre de 2012, a les 19:41:26, Thomas
>>>>>> Freitag va
>>>> escriure:
>>>>>>> On 14.10.2012 17:21, Albert Astals Cid wrote:
>>>>>>>> El Diumenge, 14 d'octubre de 2012, a les 13:47:29,
>>>>>>>> Thomas Freitag va
>>>>>> escriure:
>>>>>>>>> Hi folks!
>>>>>>>>>
>>>>>>>>> Is there anybody in the community who wants the
>>>>>>>>> possibility to simulate overprint in qt library? With
>>>>>>>>> the implementation of DeviceN support in splash this
>>>>>>>>> is quite easy now, so I can upload a patch.
>>>>>>>> Sure, why not? Let's see the patch :-)
>>>>>>> Okay, here it is.
>>>>>> The two new methods are missing @since markers (and also i
>>>>>> think the documentation of the two methods could be a bit
>>>>>> more explanatory)
>>>>> @since: I thought that You insert it when You commit it. If I
>>>>> would insert 0.22.0 You have to change it if You will not
>>>>> have the time to commit it :-) or I need to change it and
>>>>> have to upload a new patch if You will not have the time :-(
>>>> Well, if you do it, it's less work i have to do and thus it's
>>>> easier i'll have time ;-)
>>> Because I removed these two new methods now there is no need to
>>> comment them anymore :-) But I introduced a new (static) method
>>> "okToUseOverprint" which just proofs if poppler is compiled with
>>> SPLASH_CMYK, and there I add the @since comment now.
>>>
>>>>> Explanatory: Okay, but this will be hard. For those who know
>>>>> what overprint is the documentation is self-explanatory, for
>>>>> others I need to write reams. What's about to insert the link
>>>>> to http://en.wikipedia.org/wiki/Overprinting?
>>>> To be honest doesn't seem to make things much clearer to me :D
>>> Okay, let me try to explain it in my own words: First of all, in
>>> the normal behaviour, if something is painted everything
>>> previously painted at this place is knocked out. This is rather
>>> simplified, because we ignore functionality like transparency,
>>> blending modes etc. Now let us have a look at the printing
>>> process with 4 different colour plates Cyan, Magenta, Yellow and
>>> Black. Without setting the overprint mode, the behaviour is the
>>> same:  if something is painted everything previously painted on
>>> every plate is knocked out. But when overprint mode is enabled,
>>> and i.e. in a DeviceN colorspace with only one process colour,
>>> let us assume Cyan, the Magenta, Yellow and Black plates kept
>>> untouched and only previously painted objects on the Cyan plate
>>> at this position are knocked out. But when You paint in
>>> DeviceCMYK, the behaviour remains the same (all is knocked out)
>>> even with overprint on, unless You set overprint mode to true in
>>> addition. With overprint mode true You need to look at the colour
>>> components You use for painting: if the a component is 0 the
>>> corresponding colour plate is left untouched again, if it is not
>>> 0 it will be knocked out again on this colour plate. If there is
>>> a additional spot colour plate, it is similar: overprint false:
>>> everything is knocked out, overprint true: if You paint with
>>> process colours only this spot colour plate is left untouched, if
>>> You paint with this spot colour, the process colour plates remain
>>> untouched but on this spot colour plate previously painted
>>> objects are knocked out. As I said, this is rather simplified,
>>> there are special rules for images, blending modes and so on and
>>> so on. A complete explanation can be found in the PDF
>>> specification. As overprint just works on colour plates, You'll
>>> see no effects when You print in RGB as on a monitor, therefore
>>> You have to simulate the effects (overprint preview :-) ) if You
>>> want to see them on a monitor.
>>>
>>>> Ok, let's leave the docu as it is
>>>>
>>>>>> Also why are you calling it "overprint preview"? How is it
>>>>>> a preview?
>>>>> To be honest, I haven't really thought about that. Probably I
>>>>> choose that name because it is also introduced in
>>>>> GlobalParams with that name. But also in the acrobat reader
>>>>> preferences it is called "Use overprint preview". And because
>>>>> not all RIPs support it (i.e. RGB printers) it is indeed
>>>>> something like a preview (for RIPs which support it).
>>>> Ok, let's leave it with that name (but maybe make it a
>>>> RenderingHint as Adam suggests?).
>>> I tried to understand what You meant with RenderingHint and made
>>> it, hopefully it is what You meant. I attach the changed patches
>>> (poppler and okular).
>> Looks good, I've made some changes (to try to make the roundtrip
>> faster if you agree to them)
>>
>> Rename Document::okToUseOverprint to isOverprintPreviewSupported
>> like we had for the cms stuff
> This seems a better way to name it as the old one would suggest it is
> a per-document property which it is not.
>
>> Put back the thing that creates the splashoutputdev and do the same
>> we do with antialias in the hint changes but for overprint (I don't
>> really see why we need this code shuffling around, so i'm trying to
>> minimize the diff size which hopefully minimizes the impact for
>> other features than this one)
> While the change is not strictly necessary, the new
> Document::setRenderHints, Document::getOuputDev and also
> DocumentData::setPaperColor show why it makes things much simpler.
> (Looking at the patch: If we add "delete m_outputDev;" to the end of
> the latter shouldn't there be a "m_outputDev = NULL;" as well?)
>
> I also think that there should not be any fallout from this change
> since the member "DocumentData::m_outputDev" is gone afterwards, hence
> any code that still relies on a pre-created output device would have
> been spotted by the compiler.
>
> (And there is also Thomas' threading patch which would also introduce
> those changes to the output device creation.)
>
>> Do not set the overprint hint if isOverprintPreviewSupported is
>> false
> Makes sense.
>
>> Rename the getXBGRPtr to convertToXBGRPtr since it does a lot more
>> than what you'd expect a getter to do
> I agree.
>
> Best regards, Adam.
>
>> What do you think?
Every of Your comments (Albert's and Adam's) sound reasonable for me.

Cheers,
Thomas
>>
>> Cheers, Albert
>>
>>> Cheers, Thomas
>>>
>>>> Cheers,
>>>>
>>>> Albert
>>>>>> Given that overprint only works if defined(SPLASH_CMYK) you
>>>>>> should make the setter return a boolean that says if the
>>>>>> set worked or not (i.e. make it fail if
>>>>>> !defined(SPLASH_CMYK))
>>>>> Gotcha. I thought about that and disable / enable the option
>>>>> in okular if the format generator doesn't support it. But
>>>>> because I'm not familiar enough with okular I defered it and
>>>>> then forgot it... I'll insert it in QT when I get answers to
>>>>> the other points.
>>>>>
>>>>> Cheers, Thomas
>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Albert
>>>>>>> In a few places it has already a similar implementation
>>>>>>> than in bug 50992 (thread safe), because changing the
>>>>>>> overprint option also meant that we need a different
>>>>>>> SplashOutputDev instance. But You probably also want to
>>>>>>> test it in okular? Even if we are here not on an okular
>>>>>>> list, I attach the okular patch here, too. Also here, it
>>>>>>> has already the changes from bug 50992. But because
>>>>>>> POPPLER_QT_THREADSAFE is not defined here, it doesn't
>>>>>>> make any difference, so I let these changes as they are.
>>>>>>> BTW, I'm not really familiar with qt programming, so most
>>>>>>> changes in okular are more or less a (hopefully) best
>>>>>>> guess.
>>>>>>>
>>>>>>> Cheers, Thomas
>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Albert
>>>>>>>>> For everybody who doesn't know anything about
>>>>>>>>> overprint I attach three screenshots which shows the
>>>>>>>>> implementation in okular. (This is not fake, I made a
>>>>>>>>> small apprentice piece today morning :-) )
>>>>>>>>>
>>>>>>>>> Cheers, 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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJQhiJIAAoJEPSSjE3STU343GAH/18W/wzaAK38SrIBwa1G8Q6m
> LBSx1ruQX2pi8+SQ64V/vbEJxK9AptpFxIWS4Qn+5etch6YrN9v7uTu+91qLLuNk
> JPi91I1Gyk/fMEpW5nKKdZjIpXDNSyM7+rV8a7rESfado9RjKYXrppecmqS1C+pK
> Ceyd6SYfnAzXs2QVJPcCNLcK9B4GBmCW218bWY6odyxczN3w0M12BNKZpnTZJ+7p
> 1Hs6RtSeUZVCZdydcqu67rTXdcQwewE0fBic2UREORpQAkGGLTm8afu+gVkqr3hQ
> /CkV9oBRMx+25RSWgAFILu2xyBSPB/EOap8VSs+BnmyoxY+JAyJeOZNfcl4TpeI=
> =m0pl
> -----END PGP SIGNATURE-----
> _______________________________________________
> poppler mailing list
> poppler at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/poppler
>
> .
>