🚀 go-pugleaf

In article <3966@ecicrl.ocunix.on.ca> clewis@ferret.ocunix.on.ca (Chris Lewis) writes:

>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)

Here's the crux of the problem:  DOS type applications don't generally
(and shouldn't need to) know where their print output is physically
connected.  However, the typical case is that output to an LPT device
will directly drive an attached device, and typical PC operating
conditions make it impossible to guess the state of the printer as
a job is started.  When you connect a PC to a network, the application
continues to output to the LPT device and is normally unaware that
the network code has redirected the output.     

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

The problem is you can't guarentee correct operation of the printer
without generating a stream that is invaild postscript.

>>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.

The application has to know how the printer is connected *now* unless
you are willing to force the user to turn the printer off every time
he interrupts a printout in the (rare) case where a spooler is present.
Coalescing Postscript is already a special case - adding a "newjob"
operator wouldn't make it impossible. 

>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.

But the spooler/driver can't handle anything if it doesn't exist...
More to the point, why should it be device-specific to tell the
printer that you are starting a new job and that if it hasn't received
an EOF from the last one it should pretend that it had.  Then every
piece of postscript that expects to be printed alone could start with
that operator and every piece of code that handles inclusions could
redefine it temporarily just like showpage is currently handled.  Of
course that still leaves a window where the printer can be left in
a strange state if you interrupt output to it while the "newjob" operator
is redefined.  Maybe the ^D hack isn't so bad after all.  We just
need anything that is smart enough to add one to the stream to also
be smart enough to delete extra ones.

Les Mikesell
  les@chinet.chi.il.us