spenton@ssl.berkeley.edu (Steve Penton) (03/08/91)
Would AnyOne working on an iwscript-type for the HP LaserJet
series contact me about combining forces on such a noble project.
Steve Penton
spenton@ssl.berkeley.edu
/_____________ /| Steve Penton
| | | spenton@ssl.berkeley.edu
| Figliano! | | Center For EUV Astrophysics
| | | University Of California @ Berkeley
|_____________ |/ 2150 Kittredge St., Berkeley CA,94720araftis@polyslo.CalPoly.EDU (Alex Raftis) (03/09/91)
In article <1991Mar8.084732.12215@agate.berkeley.edu> spenton@ssl.berkeley.edu (Steve Penton) writes: > >Would AnyOne working on an iwscript-type for the HP LaserJet >series contact me about combining forces on such a noble project. > > 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. I suggest writing an iwscript type program that uses a configuration file or another configuration program to implement printing for all printer. Wordperfect for PC's manage to do something similar to this, and it'd be much more useful than thirty different projects for thirty different printers when 90% of the code will be identical. Any takers? -- -------------------------------------------------- Internet: araftis@polyslo.CalPoly.EDU America Online: xela (Real Life: Alex Raftis)
eps@toaster.SFSU.EDU (Eric P. Scott) (03/11/91)
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=-