Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!pacbell.com!decwrl!adobe!taft
From: taft@adobe.com (Ed Taft)
Newsgroups: comp.lang.postscript
Subject: Re: Negative needed
Message-ID: <14328@adobe.UUCP>
Date: 23 Apr 91 00:47:55 GMT
References: <1991Apr11.124626.12325@pbs.org> <1947@chinacat.Unicom.COM> <1991Apr17.141806.20838@shell.shell.com> <1991Apr18.224028.21519@cl.cam.ac.uk>
Sender: news@adobe.COM
Reply-To: taft@adobe.COM (Ed Taft)
Organization: Adobe Systems Incorporated, Mountain View
Lines: 26

In article <1991Apr18.224028.21519@cl.cam.ac.uk> cet1@cl.cam.ac.uk (C.E. Thompson) writes:

>Adobe presumably realise by now that it was a bad mistake to recommend   
>using a device-dependant part of the graphics state to achieve device-  
>independant effects.

Indeed so! The most troublesome example of this is the "pattern fill"
technique, using a halftone screen to produce a repeating pattern. This
technique seemed clever at the time it was invented, but it has caused no
end of compatibility headaches. This is what led us to distinguish between
"specification" and "rendering" and to describe them in separate chapters in
the second edition of the red book.

Although Chris's advice regarding device-independent effects is excellent,
it may not apply in this case. I no longer have the original article in this
thread, but I believe its author wished to take an existing PostScript
document and render its output as negatives instead of positives. It's
reasonable to use the transfer function to achieve this, since the user
desires to obtain a specific effect on a specific device. This is quite
different from the case in which the application generating the document
fiddles with the transfer function as part of specifying colors.

Don't forget to do an erasepage after settransfer so the background color is
correctly mapped through the new transfer function.

Ed Taft      taft@adobe.com      ...decwrl!adobe!taft