Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!rpi!bu.edu!m2c!umvlsi!umaecs!gerst
From: gerst@ecs.umass.edu
Newsgroups: comp.sys.next
Subject: Printer drivers
Message-ID: <12017.278b1e8a@ecs.umass.edu>
Date: 9 Jan 91 13:45:46 GMT
Lines: 62


>Subject: Re: SUMMARY: NeXT Floppy Drive and Printer
>From: smb@csn.org!datran2
>Sender: Steven M. Boker
>
>In article <8033@hub.ucsb.edu> ye@henri.ucsb.edu (Hong Ye) writes:
>>Laser Printer:
>> [ comment about NeXT opening the printing architecture and
>>   drivers for third party printers ]
>
>This is certainly do-able.  In fact Data Transforms has been writing
>and selling printer drivers for bitmap printers for 10 years now. (We
>don't all have the luxury of institutional support)  I do have one
>observation about this.  The bitblasting printer port that connects
>to the NeXT printer operates at speeds far exceeding those supported
>by an RS232 laser printer.  A full page bitmap at 300dpi is 7,560,000
>bits.  This a little more than 13 minutes per page at 9600 baud. 
>Printers capable of 38.4kbaud will be able to get this down to a little
>over 3 minutes per page.  Thats a long wait.  After you've waited a
>half hour to get a 10 page document, the price of the NeXT printer
>doesn't look so bad.
>

Hmm, seeing as how the bottleneck here is the communications, a well
designed and implemented printer driver should do everything to reduce
the bottleneck at both ends, while at the same time, not creating more
bottlenecks.

Some things to consider:

     Most printers have a built in graphics "language" and microprocessor.
     Output tends to have a lot of whitespace or black.

Sending a raw bitmap may not be the answer for a lot of output.  The
printer graphics "languages" Ive seen have things like 'repeat pattern' &
'skip line' & 'skip'.  A "intelligent" printer driver would do something
marginally smart and scan the bitmap generating sequences of 'fills' and
'skips' when it is shorter than sending the bitmap.

A single 8" scan line at 300dpi is around 300 bytes, when this can be 
reduced to a couple byte 'graphics newline' when it is all white, or
a 'fill' when it is all black then your communications bottleneck starts
to shrink considerably.

Not all printer graphics "languages" are created equal, and this may not apply
everywhere, but it is definitely something that should be done if possible.

Similar things have been done in full screen terminal libraries. 

How long has your company been writing printer drivers for?

I'd go on, but you get the point...

>Steve

>-- 
> #====#====#====#====#====#====#====#====#====#====#====#====#====#====#====#
> #  Steve Boker           #  "Badgers, we don't have no stinking badgers"   #
> #  datran2!smb@csn.org   #    -from Treasure of the Sierra Madre Zoo       #
> #====#====#====#====#====#====#====#====#====#====#====#====#====#====#====#

Chris Lloyd - lloyd@ucs.umass.edu