Home > Archive > PostScript > December 2005 > The truth about setoverprint
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
The truth about setoverprint
|
|
| hoffmann@fho-emden.de 2005-12-04, 6:59 pm |
| The PLRM says:
setoverprint sets the overprint parameter in the graphics state
to bool. On output devices capable of producing separations or of
generating composite outputs in multiple colorants, this parameter
controls whether painting in one separation or colorant causes
the corresponding areas of other separations or colorants to be
erased (false) or left unchanged (true).
PSAlter says: not valid for composite printers.
I'm using a high end toner printer. Overprinting for black doesn't
work, neither by PageMaker nor explicitly in EPS graphics.
It may be device dependent, but there is still a contradiction
between PLRM and PSAlter.
Best regards --Gernot Hoffmann
| |
| François Robert 2005-12-05, 8:08 am |
| hoffmann@fho-emden.de wrote in news:1133722594.294410.113230
@g14g2000cwa.googlegroups.com:
> I'm using a high end toner printer. Overprinting for black doesn't
> work, neither by PageMaker nor explicitly in EPS graphics.
Overprinting in /DeviceCMYK colorspace has some arguably counter-intuitive
effects. Adobe actually felt compelled to add an "overprint mode" that
changes that behavior. See :
http://partners.adobe.com/public/de...45overprint.pdf
In a nutshell "setoverprint" applies only to colorants *OUTSIDE* the
current colorspace. As a corollary, all four process colorants of
/DeviceCMYK are *knocked out* by other marks made in CMYK. In particular,
CMYK white (0 0 0 0) or CMYK black (0 0 0 1) are "knock-out" colors in all
C,M,Y and K color planes.
If you want CMYK zero-component to become transparent (as many expect when
talking about "overprint color"), you need to use "setoverprintmode" first.
________________________________________
_______________
François Robert
(to mail me, reverse character order in reply address)
| |
| hoffmann@fho-emden.de 2005-12-05, 7:04 pm |
| Fran=E7ois,
thanks for the link and the interpretation.
Obviously no chance to get black overprinting
by the composite toner printer.
Best regards --Gernot Hoffmann
| |
| François Robert 2005-12-05, 7:04 pm |
| hoffmann@fho-emden.de wrote in news:1133800240.765250.141190
@g44g2000cwa.googlegroups.com:
> Obviously no chance to get black overprinting
> by the composite toner printer.
It is not said. Internally those machines do perform separations...
Another interpretation is that the ultimate, physical rendering
colorspace is CMYK, but some intermediate calculations alter the
requested color and thus the final colorant mix.
For instance, we have a color Lexmark in the office which claims to have
a /ProcessColorModel /DeviceRGB in its pagedevice dictionnary. When you
open the cover, you can clearly see Cyan, Magenta, Yellow and Black
toners... So some additionnal conversion / fancy / color management is
made (indeed the Color Rendering Dictionnary converts back from RGB to
CMYK via large lookup tables) and in the process, it is quite possible
that 'CMYK' components that where zero became smallish, non-zero values
thus defeating the effect of "setoverprintmode".
On a different topic, (but on the same printer) I have also noticed for
instance that it would produce a rich black (Cyan + Black I believe)
even when requested to produce a normal (0 0 0 1) CMYK black. In the
same page, I actually got mix of rich and normal black even though I
only asked "0 setgray"...
Presumably, such a behavior can be controlled / disabled, but that would
be a device dependent command.
________________________________________
_______________
François Robert
(to mail me, reverse character order in reply address)
| |
| hoffmann@fho-emden.de 2005-12-05, 7:04 pm |
| Fran=E7ois,
I'm using for these tests strictly CMYK and no further
conversion.
But you're right, handling gray images is very difficult,
because a Grayscale is neither RGB-Gray nor CMYK-K-only,
unless further informations are available for the RIP or
printer driver.
Result of a lengthy investigation (finally successful):
http://www.fho-emden.de/~hoffmann/oki-ps-28082005.pdf
The question is still not answered: what means PLRM by
overprinting for composite printers ? It should work:
K-black on top of the background without knock-out.
Best regards --Gernot Hoffmann
| |
| Roger Willcocks 2005-12-05, 9:57 pm |
| <hoffmann@fho-emden.de> wrote in message
news:1133805830.692260.270450@g43g2000cwa.googlegroups.com...
> The question is still not answered: what means PLRM by
> overprinting for composite printers ? It should work:
> K-black on top of the background without knock-out.
'Composite printers' in this context mean ones where the CMYK+spot colours
are converted to a different representation (8-bit palette colour, or rgb,
for instance) before they are painted to the frame buffer. Once a particular
colour has been painted there's no way to change just one of its process
colour components, because by definition a Postscript device will not read
back from its frame buffer.
Devices capable of in-rip separation (i.e. those which maintain separate
frame buffers for each process and spot plate) can do overprint (i.e.
non-knockout) black by using a '/Separation Black' colourspace.
Note though that if you specify a separation for which no plate exists, an
equivalent process colour will be used that will affect all the process
plates.
Black overprint is sufficiently common that some Postscript devices have an
'enable black overprint' option which treats the CMYK colour (0,0,0,1)
specially. The level 3 'setoverprintmode' operator can achieve a similar
effect.
It might not be obvious, but you can only do non-knockout black if you have
a separate black plate.
--
Roger
| |
| hoffmann@fho-emden.de 2005-12-06, 3:57 am |
| Roger,
thanks for the explanations. I had some hope that my Oki
printer could overprint K because the machine has four drums,
equivalent to four plates.
Best regards --Gernot Hoffmann
| |
| Aandi Inston 2005-12-06, 7:05 pm |
| hoffmann@fho-emden.de wrote:
>The PLRM says:
>setoverprint sets the overprint parameter in the graphics state
>to bool. On output devices capable of producing separations or of
>generating composite outputs in multiple colorants, this parameter
>controls whether painting in one separation or colorant causes
>the corresponding areas of other separations or colorants to be
>erased (false) or left unchanged (true).
>
>PSAlter says: not valid for composite printers.
What the PLRM is really referring to is that certain devices simulate
overprint in order to provide accurate proofing. That is, although
setoverprint is not really supposed to do anything on a composite
device, the device simulates the process of creating separations, and
then recombining them. Often such devices can also recombine
preseparated output and do colour profile matching.
This is a feature of high end proofers only, often optional.
>
>I'm using a high end toner printer. Overprinting for black doesn't
>work, neither by PageMaker nor explicitly in EPS graphics.
As mentioned, overprinting process colors is a very fraught and device
dependent process even when making separations.
>
>It may be device dependent, but there is still a contradiction
>between PLRM and PSAlter.
>
>Best regards --Gernot Hoffmann
>
----------------------------------------
Aandi Inston quite@dial.pipex.com http://www.quite.com
Please support usenet! Post replies and follow-ups, don't e-mail them.
| |
| hoffmann@fho-emden.de 2005-12-06, 7:05 pm |
| Aandi,
yes, probably correct according to your experiences.
But high end proofing systems use nowadays inkjets
(more precisely: my high end proofing systems use an
inkjet, and a less accurate system uses the toner printer).
No mis-registration for the inkjet then.
Simulating Black on Red colorimetrically would be
meaningless - looks anyway black for text and lines.
I'm really not talking about overprinting spots or process
colors (others than 100%K on top).
It seems that overprinting is not handled correctly
(equally) in various PostScript systems.
Best regards --Gernot Hoffmann
| |
| Roger Willcocks 2005-12-06, 7:05 pm |
|
<hoffmann@fho-emden.de> wrote in message
news:1133893005.442556.36240@o13g2000cwo.googlegroups.com...
> It seems that overprinting is not handled correctly
> (equally) in various PostScript systems.
'Because the effect of the overprint parameter is device dependent,
_setoverprint_ should not be used in a program that is intended to be
device-independent.'
PLRM III, p. 678
--
Roger
|
|
|
|
|