Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!haven!mimsy!aplcen!osiris!phil
From: phil@osiris.UUCP (Philip Kos)
Newsgroups: comp.lang.postscript
Subject: Re: Host software alternatives to PS engines?
Summary: medium-long
Message-ID: <1687@osiris.UUCP>
Date: 19 Sep 88 19:33:16 GMT
References:  <599@sering.cwi.nl>
Reply-To: phil@osiris.UUCP (Philip Kos)
Organization: Johns Hopkins Hospital
Lines: 54

Random thoughts, bald-faced assumptions, generalizations, and probably some
damned lies ahead.  Correct if you feel obligated, contradict me if you feel
like it (I love a good bloody argument).

I thought for awhile about the differences between doing the PostScript
interpretation in the printer (as in an Apple LaserWriter) and doing it in
your PC or whatever, and here are some observations I came up with.  I'm
curious as to whether anyone at all will agree with me.  ;-)

+ An "onboard" (i.e. running inside the main system) PostScript "engine"
  will communicate with the host system via its bus, and with the print
  "engine" via a system I/O port.

+ A system's bus will tend to have much more bandwidth than any one of its
  I/O ports.

+ Input to the PS "engine" is a relatively small amount of PS data to be
  interpreted and converted to printing engine data.

+ Output from the PS "engine" is a relatively large amount of data (in
  general, compared to its input).

+ Putting the PS engine inside the host computer pretty much forces it (for
  reasons of simplicity if nothing else) to get its input (small) from the
  system bus (high-speed) and send its output (large) out a system I/O port
  (low-speed).  Can you say "bottle-neck"?

+ Putting the PS engine inside the printer pretty much forces it to get its
  input (small) from the printer's I/O port (low-speed) and send its output
  (large) over the printer's internal bus (high speed).

+ The minimum latency of any multi-stage pipeline cannot be less than the
  maximum single-stage latency.

+ Deliberately designing a system so that it contains bottlenecks or other
  artificial flow restrictions is not a really great idea, although in the
  case of commercial products it provides a very convenient upgrade path so
  is done occasionally (I'm not joking, many otherwise-well-respected
  companies have been known to do such things).

My personal conclusion is that it makes a lot more sense to put the PS
engine in the printer.  As a respondent noted, having it in the PC gives
you the opportunity to send the "dots" (assuming the PS engine is driving a
raster device, which is probably one of the safest assumptions I've seen
this month) to the screen instead of the printer.  This may be true but I'd
hate to have to wait while a scan conversion program went from the 200+ dpi
of the typical raster printer to the <100dpi of the typical monitor.  The
output from a PS engine tends to be HIGHLY device-dependent, and for reasons
of performance will probably remain so for at least another generation of
silicon.

                                                                 Phil Kos
                                                      Information Systems
...!uunet!pyrdc!osiris!phil                    The Johns Hopkins Hospital
                                                            Baltimore, MD