[poppler] Implement overprint in qt interface?

Adam Reichold adamreichold at myopera.com
Wed Oct 24 09:57:45 PDT 2012 

On 24.10.2012 18:45, Albert Astals Cid wrote:
> El Dimarts, 23 d'octubre de 2012, a les 06:51:20, Adam Reichold va escriure:
> 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?)
> 
>> Yes, there is a = NULL missing, i'll add it when i find some time, note i'm on 
>> a business travel until Nov 1st so my time is ultra limited until then.
> 
> 
> 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.
> 
>> I'm not oposing to that change, it's just a separate change, not needed for 
>> this feature, let's keep features/fixes/cleanups in separate commits :-)
> 
>> Cheers,
>>   Albert

Sorry, I misunderstood you there. The policy sounds very reasonable.
Thanks for a lot of work with limited resources!

Regards, Adam.

> (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?
>>>>
>>>> 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
> 
>> _______________________________________________
>> 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
>

More information about the poppler mailing list