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