Path: utzoo!news-server.csri.toronto.edu!rutgers!uwm.edu!bionet!agate!ziploc!eps
From: eps@toaster.SFSU.EDU (Eric P. Scott)
Newsgroups: comp.sys.next
Subject: Re: IWSCRIPT-Type Program for HP LaserJets - Lets Get It Done
Message-ID: <1424@toaster.SFSU.EDU>
Date: 10 Mar 91 23:43:10 GMT
References: <1991Mar8.084732.12215@agate.berkeley.edu> <27d7e458.603e@petunia.CalPoly.EDU>
Reply-To: eps@cs.SFSU.EDU (Eric P. Scott)
Distribution: usa
Organization: San Francisco State University
Lines: 29

In article <27d7e458.603e@petunia.CalPoly.EDU>
	araftis@polyslo.CalPoly.EDU (Alex Raftis) writes:
>Here's an even better idea. I've noticed that many printers handle bitmaps
>in similar manners. They might change the codes to begin dumping, and they
>may use seven or eight bits, but there are definite similarities.

There are two problems with this: (1) it's not really true,
(2) most "dumb" printers are a lot smarter than the NeXT Laser
Printer.

(1) There's "something that works" and "something that works
really well."  While most printers have a "the next N bytes are
image data" command, if there are more sophisticated
alternatives, it often wins to use them.  I didn't implement RLE
in iwf simply because the serial port operates so much faster
than the ImageWriter II printhead can keep up.  But the hooks
were in the code.  When you get to something like an HP printer
with its area fills and whatnot, dumping straight rasters doesn't
look very attractive.
(2) When you are printing straight text (source code listings,
etc.) the printer's built-in character generation is no doubt
going to look a lot better and run a lot faster than anything
using the NextStep Window Server.  That's why iwf implements
two separate device-dependent filters in the same executable.

It is possible for a package to support "300 different
printers" but that's a *much* harder problem.

					-=EPS=-