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