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