Path: utzoo!attcan!uunet!husc6!purdue!decwrl!adobe!greid
From: greid@adobe.com (Glenn Reid)
Newsgroups: comp.lang.postscript
Subject: Re: what about color laser printers?
Keywords: LaserWriter, PostScript
Message-ID: <137@adobe.COM>
Date: 21 Dec 88 23:12:53 GMT
References: <1667@valhalla.ee.rochester.edu> <113@adobe.COM> <6505@pogo.GPID.TEK.COM>
Sender: news@adobe.COM
Reply-To: greid@adobe.COM (Glenn Reid)
Organization: Adobe Systems Incorporated, Mountain View
Lines: 65

In article <6505@pogo.GPID.TEK.COM> jacks@pogo.GPID.TEK.COM (Jack Slingerland) writes:
>If we take the red book as  the definition of the language at "Day 1", then
>at Day 1 the language allowed for setting a current painting color
>(setrgbcolor and sethsbcolr), and for querying the interpreter for the
>current color setting (currentrgbcolor and currenthsbcolor).  There was
>no provision for color in the raster operators.
>
>In 1988 ("Day 1" + 3 years), Adobe published "PostScript Language Color
>Operator Definitions" which defined a new color model (cmyk) and the
>following new operators:
>
>         setcmykcolor                  currentcmykcolor
>         setcolortransfer              currentcolortransfer
>         setblackgeneration            currentblackgeneration
>         setundercolorremoval          currentundercolorremoval
>         setcolorscreen                currentcolorscreen         
>         colorimage (in 5 flavors)

This (and other similar messages) is all quite correct.  Perhaps the
original response was a little misleading.  Unfortunately, all of you
are much too sophisticated out there; you don't miss anything :-)

I think that there are several levels of "having color", and it depends
on what you mean.  For example, there are:

	* a color imaging model and the ability to specify color
	* an interpreter having the above operators
	* having a real live color frame buffer and color marking engine, etc.

We at Adobe often get asked the question of whether or not we had to
completely re-engineer the language and the interpreter to support
color.  The answer is no, in the sense that the abstraction of color
and the ability to represent full color in the graphics state and the
painting operations has been there all along.  That is really the hard
part.  Having "setrgbcolor" is just the tip of the iceberg.  It is the
underlying rasterization that has to have a good notion of color built
in.  I (hesitantly) suggest looking at QuickDraw for an example of
post-engineering color into the imaging model.

The recent PostScript language extensions for color added some
capability to express or specify color, which was needed.  We also
plugged in some more memory and made full color frame buffers and
things like that, which you need, and sent the output to a color
marking engine (and did halftoning and lots of other miscellany).

But the spirit of the original message was that the *imaging model* and
the language has contained support for color "since Day 1", which
actually is important, because we haven't had to re-engineer and debug
all the hard stuff in the middle that is concerned with imaging.

I hope this helps clear things up a little bit.  Thanks for all the
responses that correctly point out that we have, in fact, added quite a
bit to support Color.

And therefore I, for one, think it is reasonable to talk about "Color
PostScript".  However, I don't think it is specific enough.  For
example, if you built in "colorimage" and "setcmykcolor" into a
black-and-white printer, in the same way that "setrbgcolor" is there,
would you have a "Color PostScript" printer?  I don't think so.

Holiday cheers....

Glenn Reid
Adobe Systems
Mountain View