kent@lloyd.camex.uucp (Kent Borg) (05/19/89)
For those of you who have gotten your hands on the new LaserWriter 6.0 and 32-Bit QuickDraw: have you gotten it to work? I am running a IIx with lots of memory and the Apple color monitor, only 6.0.3, the new LaserPrep and LaserWriter, 32-bit QuickDraw, the new Monitors, and the new General in the Blessed Folder, am talking to a PhoneNET-ed LaserWriter Plus (with a Kinetics FastPath 4 listening in). What happens is usually nothing when there are color bit maps in whatever I am printing. For a while I was getting ``Error: limitcheck; OffendingCommand: framedevice'', but powercycling the printer made that go away. Usually it is happy just sitting there forever: an hour in one case, trying to print one of Apple's own samples using Apple's own PICTViewer. Even PICT Detective--which I know knows about 32-Bit QD--just sits there claiming to be processing. My boss has been having better luck with a Macintosh II and a big color Radius talking to a NTX-what-ever-it-is, he gets output, but what used to be 5 minutes is now 25 minutes, and he says the images are the wrong size. Anybody know how to get this new-and-improved software to *act* new-and-improved? Kent Borg kent@lloyd.uucp or ...!hscfvax!lloyd!kent
dplatt@coherent.com (Dave Platt) (05/23/89)
In article <404@lloyd.camex.uucp> kent@lloyd.UUCP (Kent Borg) writes: > For those of you who have gotten your hands on the new LaserWriter 6.0 > and 32-Bit QuickDraw: have you gotten it to work? > .... > What happens is usually nothing when there are color bit maps in > whatever I am printing. For a while I was getting ``Error: > limitcheck; OffendingCommand: framedevice'', but powercycling the > printer made that go away. Usually it is happy just sitting there > forever: an hour in one case, trying to print one of Apple's own > samples using Apple's own PICTViewer. Even PICT Detective--which I > know knows about 32-Bit QD--just sits there claiming to be processing. > My boss has been having better luck with a Macintosh II and a big > color Radius talking to a NTX-what-ever-it-is, he gets output, but > what used to be 5 minutes is now 25 minutes, and he says the images > are the wrong size. > > Anybody know how to get this new-and-improved software to *act* > new-and-improved? I recently had a discussion with a person who has examined the LaserWriter 6.0 color-compatibility code in some detail. I've been working with some custom PostScript code designed for a similar purpose, and was considering letting it expire gracefully and switching over to the 6.0 LaserWriter code when it's available. I was told "Don't depend on the 6.0 code; it's extremely slow". The reason, as stated to me, is this: the 6.0 driver sends the full 24-bit R/G/B tuple down to the printer, for each and every pixel in the color PixMap. If the user has requested color printing, the data is displayed using the "colorimage" operator. If the user has requested grayscale printing, the R/G/B tuples are fed into a conversion function that calculates the lightness of the tuples (using the NTSC color model, or so I'm told), and then fed into the "image" operator. This procedure is extremely general... it works with grayscale PixMaps, 4- or 8-bit color PixMaps, and with 16-, 24-, or 32-bit-deep PixMaps. If the printer is capable of handling 24-bit color information, then all of the colors in the original image will be reproduced correctly. It is, however, _extremely_ slow when grayscale halftoning is being done. I was told that the RGB->lightness mapping is being done for each pixel, independently, in the printer. The 6.0 driver does _not_ optimize this process when sending down 8-bit-deep pixmaps (in which the RGB->lightness calculation could be performed once per color for each PixMap being sent). I don't know whether the RGB->lightness mapping is implemented in interpreted PostScript code, or whether it's part of Apple's magick LaserWriter-specific 68000 code (a la the bitsmoothing code). Some color-capable applications may be substantially slower when using the 6.0 driver... if they "see" that LaserWriter 6.0 is providing a color GrafPort, and use its color capabilities rather than generating customized PostScript "image" code, their performance may decrease quite a bit. Disclaimer: most of the above information comes to me second-hand; I haven't yet hacked the 6.0 LaserPrep file to see if things are as inefficient as I've been told they are. -- Dave Platt FIDONET: Dave Platt on 1:204/444 VOICE: (415) 493-8805 UUCP: ...!{ames,sun,uunet}!coherent!dplatt DOMAIN: dplatt@coherent.com INTERNET: coherent!dplatt@ames.arpa, ...@uunet.uu.net USNAIL: Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303