[poppler] Implement overprint in qt interface?

Albert Astals Cid aacid at kde.org
Fri Nov 2 14:50:25 PDT 2012 

El Dimecres, 24 d'octubre de 2012, a les 18:57:45, Adam Reichold va escriure:
> 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!

Commited! Once thing less in the queue!

Cheers,
  Albert

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

More information about the poppler mailing list