deke@valhalla.ee.rochester.edu (12/09/88)
In article <6385@pogo.GPID.TEK.COM> curtj@pogo.GPID.TEK.COM writes: >In article <4338@homxc.UUCP> mlm@homxc.UUCP writes: >>Does anyone out there use or know of a color slide or transparency machine >>that knows PostScript. > > Tektronix Phaser CP. It was announced at COMDEX.. It's a 300 DPI > color printer with both a Color PostScript Compatible interpreter as > well as an HPGL interface. It can print on both paper and trans- > parencies. > > At this point in time, it requires a PC and an expansion board, > which fits into the PC. Sounds like the "Color PostScript Compatible interpreter" is on the PC board. Is that right? What about a *color* output device that like a LaserWriter, interprets PostScript onboard? Not an ink-jet or a color thermal transfer, but a Cannon-engine type device. Do they exist? It seems to me that there is a sizeable market out here waiting for the "right" solution. Is there anyone from Adobe, Cannon, or Apple listening that would care to comment? ^Deke Kassabian, deke@ee.rochester.edu or ur-valhalla!deke Univ of Rochester, Dept of EE, Rochester, NY 14627 (+1 716-275-3106)
prc@ERBE.SE (Robert Claeson) (12/12/88)
In article <1667@valhalla.ee.rochester.edu>, deke@valhalla.ee.rochester.edu writes: > Sounds like the "Color PostScript Compatible interpreter" is on the PC board. > Is that right? What about a *color* output device that like a LaserWriter, > interprets PostScript onboard? Not an ink-jet or a color thermal transfer, > but a Cannon-engine type device. Do they exist? The QMS ColorScript color PostScript, 300 dpi printer. -- Robert Claeson ERBE DATA AB rclaeson@ERBE.SE
richard@gryphon.COM (Richard Sexton) (12/16/88)
In article <427@maxim.ERBE.SE> prc@ERBE.SE (Robert Claeson) writes: >In article <1667@valhalla.ee.rochester.edu>, deke@valhalla.ee.rochester.edu writes: > >> interprets PostScript onboard? Not an ink-jet or a color thermal transfer, >> but a Cannon-engine type device. Do they exist? Yes, but you cant buy them yet. Be patient. >The QMS ColorScript color PostScript, 300 dpi printer. Nope. It's thermal transfer. -- ``Wake me up when it's time to go to sleep'' richard@gryphon.COM {...}!gryphon!richard gryphon!richard@elroy.jpl.nasa.gov
jackson@adobe.COM (Curtis Jackson) (12/18/88)
}In article <6385@pogo.GPID.TEK.COM> curtj@pogo.GPID.TEK.COM writes: }> Tektronix Phaser CP. It was announced at COMDEX.. It's a 300 DPI }> color printer with both a Color PostScript Compatible interpreter as }> well as an HPGL interface. It can print on both paper and trans- }> parencies. Just a bit of picky education: There is no such thing as "Color Postscript". The Postscript [tm] Language from Adobe has always had full color support from Day 1. How the Postscript interpreter on a given printer chooses to implement (or not implement) color-related Postscript operators is another matter altogether... Curtis Jackson @ Adobe Systems in Mountain View, CA (415-962-4905) Internet: jackson@adobe.com uucp: ...!{decwrl|sun}!adobe!jackson Q -- Curtis Jackson @ Adobe Systems in Mountain View, CA (415-962-4905) Internet: jackson@adobe.com uucp: ...!{decwrl|sun}!adobe!jackson
jmr@nada.kth.se (Jan Michael Rynning) (12/19/88)
In article <113@adobe.COM> jackson@adobe.UUCP (Curtis Jackson) writes: >The Postscript [tm] Language from Adobe has always had full color support >from Day 1. Then the colour operator extensions added after Day 1 must have given the PostScript language an overfull colour support. Jan Michael Rynning, jmr@nada.kth.se Department of Numerical Analysis If you can't fully handle domains: and Computing Science, ARPA: jmr%nada.kth.se@uunet.uu.net Royal Institute of Technology, UUCP: {uunet,mcvax,...}!nada.kth.se!jmr S-100 44 Stockholm, BITNET: jmr@sekth Sweden. Phone: +46-8-7906288
rainero@rocksanne.UUCP (Emil Rainero) (12/19/88)
In article <113@adobe.COM> jackson@adobe.UUCP (Curtis Jackson) writes: >Just a bit of picky education: There is no such thing as "Color Postscript". >The Postscript [tm] Language from Adobe has always had full color support >from Day 1. THIS IS NOT TRUE. Synthetic graphics (yes fonts too) could use setrgbcolor and sethsvcolor operators, but there was no way to send color images (jee, maybe this is why the new operator is called 'colorimage') to 1.0 PostScript printers. The extensions for color also include a CMYK color model, color screens, color transfer functions, and support undercolor removal and black generation. My main reason for posting this message is to make clear that while it is true that color was supported from PostScript's inception, additions were necessary to claim functional color support. These extensions, as well as other problems that Apple has introduced, is why we are now seeing device specific PostScript masters being generated from Macintosh emitters. (Emil's Psychic Forecast for 1989) It is interesting to note that even with 24 or 32 bit color images, there is no built-in support for compression. (please, no flames about writing it in PostScript). With the proliferation of compression/decompression chips, I would expect to see further extensions from Adobe. -- Emil Rainero -- Xerox Webster Research Center UUCP: {seismo,allegra,decvax,cmcl2,topaz}!rochester!rocksanne!rainero Arpa Internet: Rainero.wbst@xerox.arpa
rcd@ico.ISC.COM (Dick Dunn) (12/20/88)
In article <113@adobe.COM>, jackson@adobe.COM (Curtis Jackson) writes: > Just a bit of picky education: There is no such thing as "Color Postscript". True as far as anything I've ever seen...however... > The Postscript [tm] Language from Adobe has always had full color support > from Day 1... ...seems at odds with what Adobe has done recently... I have a document, allegedly from the Adobe PostScript file server, called _Color_Operator_Definitions_, dated April 25, 1988 and copyrighted 1988 by Adobe Systems Incorporated, which claims: The PostScript language will be upgraded to support color more fully by a variety of means... ...The PostScript language currently supports color to a limited extent... ...To support color printing completely, however, a few additional operators need to be added to the PostScript Language to fill the gaps... The gist of it is that the original definition of PostScript has operators for producing color images of certain types, in certain ways. However, for other needs, it may be very difficult and/or require multiple passes. The obvious limitation is that the `image' operator cannot render a color image. To do so, it needs multiple screens (3 or 4, depending on the color model used) and pixel values for each screen. I think the grandparent article (to which Jackson responded) was probably (mis)using the term "Color PostScript" to mean "PostScript upgraded with the color image operators." It *would* be nice to have a concise term to describe this level of revision of PostScript, although I agree with Jackson that "Color PostScript" isn't right because PostScript already had color-handling concepts. -- Dick Dunn UUCP: {ncar,nbires}!ico!rcd (303)449-2870 ...Worst-case analysis must never begin with "No one would ever want..."
jacks@pogo.GPID.TEK.COM (Jack Slingerland) (12/21/88)
Curtis Jackson (jackson@adobe.COM) states: > Just a bit of picky education: There is no such thing as "Color Postscript". > The Postscript [tm] Language from Adobe has always had full color support > from Day 1. 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) It is this version of PostScript [tm] (implemented in version 49), which is meant when it is said that Tektronix's Phaser Interpreter is compatible with Color PostScript [tm]. ----------------------------------------------------------------- Jack Slingerland (503) 685-3985 Graphics Printing & Imaging Division Tektronix, Inc (MS 63-356) PO Box 1000; Wilsonville, Oregon 97070 jacks@pogo.GPID.TEK.COM ...tektronix!pogo!jacks
consult@osiris.UUCP (Unix Consultation Mailbox ) (12/21/88)
In article <627@rocksanne.UUCP> rainero@rocksanne.UUCP (Emil Rainero) writes: >(Emil's Psychic Forecast for 1989) >It is interesting to note that even with 24 or 32 bit color images, there is >no built-in support for compression. (please, no flames about writing it in >PostScript). With the proliferation of compression/decompression chips, >I would expect to see further extensions from Adobe. It seems to me that it would be pretty hard and possibly unrewarding to design a compression/decompression scheme which would turn ASCII text into ASCII text (remember that one of the fundamental ideas behind PostScript is that PS programs are strictly ASCII, thus enhancing portability) without causing any random breakage in the way the PS interpreter reads the image. Perhaps something like "compress the image then uuencode" would work, but I wouldn't bet on it myself, I'm no Glenn Reid (and neither is Brian :-). The final word, anybody? Phil Kos uunet!pyrdc!osiris!phil The Johns Hopkins Hospital
greid@adobe.com (Glenn Reid) (12/22/88)
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