[poppler] Implement overprint in qt interface?

Adam Reichold adamreichold at myopera.com
Mon Oct 22 21:51:20 PDT 2012 

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

More information about the poppler mailing list