[reportlab-users] CMYK overprinting (colour-separated PDF output)
Dom inique
is it possible to use CMYK overprinting without using the CMYKColorSep
class, which always generates a new seperate color in the printer
settings, i just want to use overprinting with the standard 4 CMYK
inks (colour-separated PDF output, as stated in the 2.4 changelog)
my example code, derived from the reportlab example: http://pastie.org/1024712
note: you need to enable the overprinting preview in adobe acrobat pro
to correctly view this.
thank you very much
_______________________________________________
reportlab-users mailing list
reportl...@lists2.reportlab.com
http://two.pairlist.net/mailman/listinfo/reportlab-users
Andy Robinson
> hi,
>
> is it possible to use CMYK overprinting without using the CMYKColorSep
> class, which always generates a new seperate color in the printer
> settings, i just want to use overprinting with the standard 4 CMYK
> inks (colour-separated PDF output, as stated in the 2.4 changelog)
Yes, use the CMYKColor class instead.
Hope this helps,
Andy
Dominique Lederer
Am 30.06.2010 um 10:45 schrieb Andy Robinson:
> On 30 June 2010 09:13, Dom inique <hak...@gmail.com> wrote:
>> hi,
>>
>> is it possible to use CMYK overprinting without using the CMYKColorSep
>> class, which always generates a new seperate color in the printer
>> settings, i just want to use overprinting with the standard 4 CMYK
>> inks (colour-separated PDF output, as stated in the 2.4 changelog)
>
> Yes, use the CMYKColor class instead.
>
> Hope this helps,
>
> Andy
thanks for your reply, but i am already using the CMYKColor class, which does not work. Please see my example, maybe i am using it wrong?
cheers
Dom
Andy Robinson
> thanks for your reply, but i am already using the CMYKColor class, which does not work. Please see my example, maybe i am using it wrong?
Apologies, I didn't read closely enough that it was the combination of
CMYK+overprint which fails.
We added overprint recently at the request of a customer who was only
using it with spot colors. It looks like this is a bug, and we'd have
to spend some time with the PDF spec, comparing our output with
working files out of Illustrator, so it may take a while before we get
to it.
If you need this fixing urgently, please consider taking out a
ReportLab PLUS subscription (see website) and we could then guarantee
a prompt fix; if you're doing proper printing I assume this is not a
hobby project! Please email me directly about this if you'd like to
discuss it.
Best Regards,
Andy
Robin Becker
>
> Am 30.06.2010 um 10:45 schrieb Andy Robinson:
>
>> Yes, use the CMYKColor class instead.
>>
>> Hope this helps,
>>
>> Andy
>
> thanks for your reply, but i am already using the CMYKColor class, which does not work. Please see my example, maybe i am using it wrong?
>
> cheers
> Dom
Hi,
the problem here may be that non-separating overprint is not controllable by the
pdf definitions; it is a function of the output device.
from the 1.7 manual
> If the overprint parameter is true and the output device supports overprinting, no such erasing actions are performed; anything previously painted in other colorants
> is left undisturbed. Consequently, the color at a given position on the page may be a combined result of several painting operations in different colorants. The effect produced by such overprinting is device-dependent and is not defined by the PDF language.
> Note: Not all devices support overprinting. Furthermore, many PostScript printers support it only when separations are being produced, and not for composite output. If overprinting is not supported, the value of the overprint parameter is ignored.
I looked inside the PDF produced by the example and there is only one setting of
the overprint control (effectively we set /op true). After that I don't see any
restore states that affect the simple CMYK drawing; I think we're not doing
anything wrong. So it could be that the acrobat tools just decide not to show
this overprint as a colour mix for this case.
That being said there is an additional parameter that affects process cmyk
overprinting that is the opm value. We don't control that parameter currently.
According to the manual when OP is true OPM controls the interpretation of zero
tint values.
Have you tried printing any of this output with a CMYK capable printer?
--
Robin Becker
Dominique Lederer
Am 30.06.2010 um 14:18 schrieb Robin Becker:
> Hi,
>
> the problem here may be that non-separating overprint is not controllable by the pdf definitions; it is a function of the output device.
>
>
> from the 1.7 manual
>> If the overprint parameter is true and the output device supports overprinting, no such erasing actions are performed; anything previously painted in other colorants
>> is left undisturbed. Consequently, the color at a given position on the page may be a combined result of several painting operations in different colorants. The effect produced by such overprinting is device-dependent and is not defined by the PDF language.
>> Note: Not all devices support overprinting. Furthermore, many PostScript printers support it only when separations are being produced, and not for composite output. If overprinting is not supported, the value of the overprint parameter is ignored.
>
> I looked inside the PDF produced by the example and there is only one setting of the overprint control (effectively we set /op true). After that I don't see any restore states that affect the simple CMYK drawing; I think we're not doing anything wrong. So it could be that the acrobat tools just decide not to show this overprint as a colour mix for this case.
>
> That being said there is an additional parameter that affects process cmyk overprinting that is the opm value. We don't control that parameter currently. According to the manual when OP is true OPM controls the interpretation of zero tint values.
>
> Have you tried printing any of this output with a CMYK capable printer?
> --
> Robin Becker
No, i dont really have the oportunity to try out printings. I am delivering PDFs to different printshops, and it would be great, if reportlab could generate files, which are showing correctly in the overprint preview.
i generated 2 pdfs from one Illustrator file and compared them with, and without checking the "overfill print" attribute in illustrator.
here is one line i copied out of the diff, which seems to be the interesting part (and the only occurence of /op):
7 0 obj
<</AIS false/BM/Normal/CA 1.0/OP true/OPM 1/SA true/SMask/None/Type/ExtGState/ca 1.0/op true>>
endobj
vs.
10 0 obj
<</AIS false/BM/Normal/CA 1.0/OP false/OPM 1/SA true/SMask/None/Type/ExtGState/ca 1.0/op false>>
endobj
regards
Dom
Robin Becker
>
............
> i generated 2 pdfs from one Illustrator file and compared them with, and without checking the "overfill print" attribute in illustrator.
> here is one line i copied out of the diff, which seems to be the interesting part (and the only occurence of /op):
>
> 7 0 obj
> <</AIS false/BM/Normal/CA 1.0/OP true/OPM 1/SA true/SMask/None/Type/ExtGState/ca 1.0/op true>>
> endobj
>
> vs.
>
> 10 0 obj
> <</AIS false/BM/Normal/CA 1.0/OP false/OPM 1/SA true/SMask/None/Type/ExtGState/ca 1.0/op false>>
> endobj
>
> regards
> Dom
in both of these dictionaries they're setting the OPM value to 1 which may be
the main difference since currently we don't touch that.
I will take a look and see if there's an obvious route to setting this easily.
We have some infrastructure in place for these extended graphics states so it
may not be too hard.
--
Robin Becker