🚀 go-pugleaf

les@chinet.chi.il.us suggests that we fix the ^D problem by making
PostScript-aware programs "remove anything that isn't postscript".

That solution will work in some environments, but not in others.  In fact,
Digital's ScriptPrinter symbiont does strip out ^D's that it finds in files
(it also strips ^S, ^Q, ^C, and ^T).  That makes sense, because the
ScriptPrinter is a serial device, and the symbiont knows that a ^D on the
wire will do the wrong thing (unless the symbiont sent it).

But how should we handle the same situation for the PrintServer 40?  There
a ^D can be sent to the printer just fine.  It really only makes sense if
the input is being read by the PostScript program, rather than the
PostScript interpreter, and it certainly won't be portable to other
environments, but does it make sense to limit the use of the printer in
this way?  Some customer may know what they are doing, and may accept that
his software won't be portable, but will opt to use full eight-bit binary
image transmission (for example) because it makes things go faster.

If we were to write the PrintServer 40 symbiont to strip out ^D's, it would
be close to an arbitrary limitation of the transparent data path to the
printer.

les@chinet.chi.il.us in the same note states that an application shouldn't
know if its output is going to a printer, a file, or another process.  I
whole-heartedly agree, with one exception.  If an application has decided
to shoulder the responsibility of controlling the printer, then it ought to
know if its output is going to the printer or not.  And writing ^D's is
part of controlling the printer.

If your application is outputting ^D, then it has to know where its output
is going.

--Ned Batchelder, Digital Equipment Corp, BatchelderN@Hannah.DEC.com