oster@dewey.soe.Berkeley.EDU (09/17/87)
Now that General Computer is selling a fairly in-expensive SCSI laser
printer similar to the design I published in comp.sys.mac, I want to
throw my two cents in.
The problem with a dumb printer is, (1) you have to live within the
restrictions of what its dumb little micro can do or, (2) you have to
send it the bitmap for an entire page. An 8"x10"x300dpi bitmap is
roughly a megabyte. It takes roughly 2 hours 15 minutes to move 8
million bytes of data at 9600 baud.
Almost all Macintosh software attempts to provide
What-You-See-Is-What-You-Get. That means that the software attempts to
show you the page you are building as it will look on the screen. The
General Computer printer takes advantage of this, and of the resolution
independence of QuickDraw, the graphics package in the Macintosh. If
the software can show it on the screen, and it follows Apple's
guidlines for writing Macintosh software, it will be able to print it
at the full resolution of the printer.
When a Macintosh application goes to print a page, the printer driver
hands the application a canvas to draw on, and a record describing the
size of the page, its margins, and the resolution (x and y) of the
printer. The application generates a series of quickdraw commands the
define the page. (Possibly augmented with postscript commands that
the printer driver is allowed to ignore.) The LaserWriter driver
translates the quickdraw commands into postscript commands, except
where there is optional postscript, it replaces the translation of the
quickdraw with the postscript.
The General Computer printer driver allocates a page buffer, 8"x10" at
300 pixels per inch, uses quickdraw to draw the page onto this bitmap,
then sends the bitmap to the printer.
The previous paragraph is an oversimplification, since most current
Macintoshs don't have a free 8"x10"x300dpi buffer available at print
time. (It is a megabyte of RAM after all.) Instead, it records the
quickdraw calls, and plays them back repeatedly. Each time, it uses
QuickDraw's clipping feature to draw into a band (for example 8"x2")
of the page. When the band is complete, it runs a data compression
algorithm on it, allocates a new band and starts again. When the
entire page is complete, it signals the print mechanism to start, and
un-compresses each band in turn, shipping it out the SCSI port. The
entire Megabyte takes about 8 seconds to send (a data rate of 1
Megabit per second,) which is also the time it takes for the laser
printer to print on one page. It works this way because a laser
printer needs access to the whole page when it goes to print. That
laser print head can't wait for something to be computed, it needs
those bits to print now.
Note, that if you do have a megabyte of free memeory at print time,
the printer driver doesn't need to record the quickdraw calls, it can
just play them onto the page bitmap directly, and if you have a second
megabyte, while bitmap 1 is going out the SCSI port to the printer,
you can be working on drawing into bitmap 2. Potentially this thing
has the potential to be much faster than the LaserWriter method of (1)
turn the quickdraw calls into postscript (2) send the psotscript over
AppleTalk to the printer (3) wait while the printer plays the
postscript to draw into its internal Megabyte page buffer (4) the
buffer prints.
If the desktop publishing package does something that QuickDraw does
not do, like binding text to a curve, if it can show it to you on the
screen, it should be able to do it on the printer at the full
resolution of the printer.
Now, what about fonts. Well, QuickDraw draws text by communicating
with the Font Manager which in turn communicates with the Printer
Driver. QuickDraw already provides for using font bitmaps, if
available, and scaling from existing bitmaps if not. The General
Computer printer driver augments QuickDraw, generating fonts from
lists of edges.
This whole system of using a non-postscript printer to do a decent job
only works because of a number of interlocking points:
1.) The SCSI port on a Macintosh can run fast enough to hand enough
bits to the laser print head, as it needs them, to actually print the
page. (Serial, or AppleTalk would have been to slow.) (You could get
away without this if you have a printer which has its own internal
1Megabyte buffer. but if your computer talks to it at 9600Baud, it'll
take about 8000 seconds (roughly 2hours 15 minutes) to send it the
data for a single page.
2.) Macintosh applications print by generating QuickDraw commands at a
canvas. They use exactly the same method to draw on the screen.
Therefore, it is easier for WYSWIG programs to do it right than not.
3.) All drawing, screen or printer, in the Mac is done with QuickDraw.
4.) QuickDraw is resolution independent. (Though I admit that it is
resolution independent in a different sense than postScript is: a
saved postScript file can be played back at any resolution,
independent of the resolution it was created at. A quickDraw picture
can be created at any resolution, and played back at any resolution,
but it looks best played back at the same resolution it was created
at.)
5.) There already exist many tools for QuickDraw fonts, QuickDraw
drawings, and QuickDraw scanned images. These plug in directly.
You _could_ make a non-postscript printer do a decent job on some
machine other than the Mac, but it would only work with those few
applications for which you provided custom drivers. By comparison, the
General Computer printer should work right with _every_ Macintosh
application. (If it doesn't work the application is broken and you can
inform the developer of that and ask that it be fixed.)
----------------------------------------
Submissions to: desktop%plaid@sun.com -OR- sun!plaid!desktop
Administrivia to: desktop-request%plaid@sun.com -OR- sun!plaid!desktop-request
Paths: {ihnp4,decwrl,hplabs,seismo,ucbvax}!sun
Chuq Von Rospach chuq@sun.COM Delphi: CHUQ
We live and learn, but not the wiser grow -- John Pomfret (1667-1703)