🚀 go-pugleaf

In article <BxEy6H.KCs@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
>In article <3944@ecicrl.ocunix.on.ca> clewis@ferret.ocunix.on.ca (Chris Lewis) writes:

>>>When printing from MS Windows to Postscript file, the file (if you don't
>>>make it not to) starts with characters ^D%! (i.e. control-D, %, !).

>>The correct way to handle this is for the application to *not*
>>append or prepend ^D's, and let the spooler handle it.

>Errr, since when does MS Windows *have* a print spooler? 

The original context was about print spoolers.  MS Windows was brought
up by someone else.  I was commenting in general.  Besides, I know that
some UNIX ports of DOS applications do the same brain damage.  Also,
if there's no spooler, who cares?  (except if your network interface
isn't smart enough to remove this grunge)

>Don't you
>think it would be pretty silly of the applications to generate output
>that wouldn't work under the most common conditions?

I would think it would be pretty silly to *force* it to generate
invalid Postscript.  A "failsafe" *option* is a different thing.

>>MS Windows use of ^D is a kludge workaround for somebody else's botch.
>>A bad kludge.  Because the output of MS Windows ain't PostScript because
>>of it.

>Yes, having a single-tasking operating system is a botch I suppose, but
>it happens a lot in the real world.  I say the botch is that postscript
>printers require the ^D  to terminate a job over the serial/parallel
>ports, yet it isn't a defined postscript command.

It would be even worse if it was "defined" in this way.  Then coalescing
PostScript (as in, including EPS) becomes a special case and complicates
everybody's life.  Not to mention that the application has to know
ahead of time how the printer is connected - which ain't none of its
business.

>If ^D or some other token (perhaps not in the control character range) had
>been included in the postscript language definition to perform this needed
>function the problem simply wouldn't exist.

If you're printing to a network device?

Either way the spooler/print driver has to special case to generate
the correct stream to be sent to the printer.  It just seems far more logical
to me to retain device independence in the application, and let the
spooler/driver handle printers-specific dependencies, than introduce device
dependencies into the application, and have the driver have to selectively
undo the application-introduced dependencies AS WELL AS introduce the
correct dependencies.
-- 
Chris Lewis; clewis@ferret.ocunix.on.ca; Phone: Canada 613 832-0541
Psroff 3.0 info: psroff-request@ferret.ocunix.on.ca
Ferret list: ferret-request@ferret.ocunix.on.ca