🚀 go-pugleaf

In article <MRL.92Aug3100200@sun4.uai.com> mrl@uai.com (Mark R. Ludwig) writes:
|In article <1992Aug2.194857.28249@cco.caltech.edu>
|carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes:

||> In article <3669@ecicrl.ocunix.on.ca>, clewis@ferret.ocunix.on.ca
||> (Chris Lewis) writes:
||> >A much better way is to fix the spooler to always emit the ^D at
||> >the end of jobs.  Applications should *not* be generating ^Ds.

||> In principal, I agree with you: Applications should not HAVE to
||> generate control-D's.  In practice, an application has no guarantee
||> that the software that sends the file to the printer will do the
||> right thing.

|I have the understanding that none of the Adobe documentation
|specifies Control-D, but that specific Postscript implementations
|require it.  (I'm sure someone will fla... uh... correct me if I'm
|wrong.)

It's generally not the implementation per-se, but more what type of
communications link you're using with the printer.  Most printers,
when they're using a parallel or serial link must have the ^D to tell
when the job ends.  Over AppleTalk, or TCP they can tell because
the network tells them so.

(Somewhere along PostScript's evolution came "stop", which can be
used instead.)

|With the above understanding, if the application knows only that the
|target printer accepts Postscript (and perhaps even the level of
|Postscript), then it is not application's business to worry about
|whether the printer needs a Control-D.

|If the application has knowledge of each precise brand and model of
|printer (and I know some do), then it's less clear.  In the
|single-user PC environment, this is unfortunately necessary, but in a
|shared environment, this detailed knowledge is A Bad Thing because it
|causes more problems than it solves.$$

The application has to know how the printer is connected.  That's
*really* none of its business, unless the application is the
spooler itself...
-- 
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