jpm@BNL.ARPA.UUCP (02/02/87)
As promised, I am sending the list a summary of the answers to my query.
I have edited the messages to delete unrelated or repeated material.
Thank You to all the people who replied, the information was a big help
(it basicly tells me that laser printer hardware is easy and a project
I'm thinking of is possible).
John McNamee <jpm@BNL.ARPA>
---------
From: gisle@oslo-vax.arpa (Gisle Hannemyr)
In the olden days, when memory was expensive, the problem was that you could
not afford enough memory to hold a full page framebuffer (a bitmap larger
0.5 Mbyte). The problem was that once paper has started rolling, it moved
at constant speed, and the laser needed to be supplied with a video signal
of a contant rate (1.1 MHz in our case). I.e. you had to be able to convert
your document from an ASCII representation to bitmap "on the fly" at that
rate.
One way to do this is to have a large number of small framebuffers, and
use them as some sort of ringbuffer.
In an engine I built around 1982 to drive the classic Canon LBP-10 laser
printer, I used 108 framebuffers each 8 scanlines high, and two processes.
One process was responsible for scanning the actual marked up text of the
document, and build the bitmaps in the framebuffers (doing Bit-Block
Transfers or "RasterOps"), the second process scanned the the framebuffers
at a contant rate, producing a 1.1 MHz bit stream that was converted to a
video signal that turned the laserbeam on and off.
Every time a buffer was completed, the filling process made it available to
the video generator, and when that framebuffer had been printed, the video
generator process, handed it back to be refilled.
Characters, vectors, splines and bitmap graphics is huge compared to the
height of an individual framebuffer, and distribute into several of them.
This adds significantly to the overhead of the system, because every object
need to be clipped against all the the framebuffers it occur in: A single 10
point character would typically require five framebuffers (10 points ==> 33
scanlines; 33/8 < 5), which meant that it needed its clippath computed five
times. Still, we had to hack all the low stuff in microcode to get it fast
enough ... and if the graphics on a page was suffiscently complex (> 1000
vectors on a page), the video generator would still overtake the filling
process, and you would get white bands across the page ... it was a pain.
With a mark-up language as rich and complex as Postscript, the only possible
solution is to have the entire page in a single framebuffer, and build the
bitmap completely before you start the paper rolling.
--------
From: jerry scharf <jerry@granite.DEC.COM>
Hi, I used to work at Imagen, and the "low level" interrface to most of
the laser printers I know of is a video stream of on and off for the
pixels. On some, the clocks are provided by he engine and others you
provide the pixel clocks.
---------
From: Henry Spencer <utzoo!henry@seismo.CSS.GOV>
I've seen sketchy specs on the Canon low-level interface; I imagine the
others would be similar, although I can't say for sure. What you send the
Canon engine is basically a funny sort of video signal, using logic levels
rather than analog ones. .... You get various hooks to control the engine:
sync pulses from the laser scanning, reports from sensing switches ("a sheet
of paper has entered the engine"), and a handful of control signals ("feed a
sheet of paper").
---------