Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!decwrl!labrea!polya!rokicki
From: rokicki@polya.Stanford.EDU (Tomas G. Rokicki)
Newsgroups: comp.sys.atari.st
Subject: Laser speed
Message-ID: <3758@polya.Stanford.EDU>
Date: 28 Aug 88 20:26:18 GMT
Organization: Stanford University
Lines: 69

Laser printers are not slow.  Adobe PostScript is no speed deamon,
but neither can you blame it for 45-minute print times.  If your
application cannot get pages out at two minutes a page, there is
something wrong with your application.

There are four main reasons presented for the slow speed of laser
printers:  interpreter overhead, font downloading, graphics
downloading, and the serial interface bottleneck.

The interpreter is not super fast (c'mon, Adobe, bind is only
half way!  Give us a modern forth if you're going to stick us
with forth.)  But neither is it slow.  If you are doing something
with the interpreter, you had better have a good reason for it.
Don't calculate in the print engine!  Use short procedure names
for the procedures you use a lot!  bind/def when you can.  Now,
my engine is a QMS PS-810A, which is much faster than a stock
LaserWriter, but even the LaserWriter isn't that slow.  The
PostScript engine is actually quite fast at rendering.  I say, if
the interpreter is your bottleneck, either you are plenty fast
(a minute a page or less) or your application is abusing PostScript.

I'll look at serial interface speeds next.  If your printer is
restricted to a serial interface, and that at 9600 baud, bitch
loudly to your printer manufacturer; they've rooked you.  The
assholes have really rooked you.  You want a parallel interface
at least, or, if your computer is up to it, a SCSI or better
interface.  There is no reason to build a laser printer with
just a serial interface, Apple notwithstanding; that one move
alone has probably cost more man-hours in waiting for all the
people using LaserWriters on parallel-capable machines than they
could possibly have saved in engineering and parts costs.  Shit,
one reason the QMS PS-810A is so preferred is because of that
parallel interface!  And Adobe, give us a better binary tranmission
standard than hex; try something like uuencode-format (with graves
in place of spaces) with special characters maybe to indicate run
encoding.  The printer can eat that up as fast as hex, and you'll
save a lot of time for everyone involved.

Graphics is next.  If your application includes some heavy
graphics, you will be penalized, but in seconds, not minutes!
The PostScript engine can draw many, many vectors per second,
and it doesn't suck at halftones either.  Maybe your software
is spending all of its time scaling coordinates?  That's what
the damned PostScript engine is good for!  I routinely draw
graphics with hundreds of edges and labeled vertices; they
print plenty fast.  640x400 grey-scale graphics take maybe a
minute each.  No 45-minute waits here!

The most difficult issue is fonts.  Resident fonts are almost
free, except the first time you use them before they exist in
the cache.  (If you use enough fonts to overflow the cache,
you probably need to reconsider your typography.)  Non-resident
soft fonts are a different story.  But if you use these, you
should download them once at the beginning of each day (or
whenever you power-cycle the printer) and *bam* they are
resident.  Buy another megabyte of memory for your printer if
you need to do so.  At 50K a font, they will take a minute or
so to download, but that's only done *once*.

You've got too many soft fonts?  Well, your software should
be able to deal with that; it can query the printer to see
if the font has already been downloaded, and if not, download
it.  Once.  Simple enough.

Maybe I'm spoiled.  But if I had a software package that took
ten minutes to print a single page, I'd return it.  And buy
something that works.

-tom