Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!zephyr.ens.tek.com!uw-beaver!Teknowledge.COM!polya!rokicki
From: rokicki@polya.Stanford.EDU (Tomas G. Rokicki)
Newsgroups: comp.lang.postscript
Subject: Re: Proper postscript file?
Message-ID: <12978@polya.Stanford.EDU>
Date: 14 Dec 89 23:29:08 GMT
References: <208400001@s.cs.uiuc.edu> <129246@sun.Eng.Sun.COM> <1989Dec14.210558.21685@ux1.cso.uiuc.edu>
Organization: Computer Science Department, Stanford University
Lines: 53

mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes:
> Concerning control-D's at the end of Postscript output from programs:

This has been discussed to death already.

> There is a big problem here. One SHOULD be able to send the output of
> a program to the printer. And get it to work. In other words,
> on MS-DOS you should simply be able to say 

> print file.psc

> and get your output. This is because Postscript is plain ASCII - 
> otherwise you would need to use binary mode.

This will indeed work---provided you insert a pause between jobs of
a minute or more.  (Most PostScript printers `infer' a ^D if they
don't get data for some settable period---usually a minute or so.)

The ^D just indicates that the job is done, and the printer can
reclaim any memory used by that job.  It's a feature, not a bug.

> IF that doesn't work, I would assume that there is something 
> wrong with the printer. It is sort of silly to have to kludge up
> some mechanism to send a control-D to a printer to get it to work.
> Requiring a "printer control program", whatever that may be, 
> is a kludge.

It's not a kludge.  It's a solution to a very real problem.  There
is a certain `state' that should be in effect at the beginning of
each job.  Without something to separate jobs, there is no way
to know when this state should be established.  Similarly, there
is no way to know how much to flush should an error occur.
(Hence the problem with some other printers---if you abort, for
instance, some graphic dump, you have to power cycle the printer
to get it to talk to you again.  Or if the printer runs out of
memory, it either locks until someone power cycles it, or it spews
out random garbage until things start working again.  Certainly
you've accidentally tried to `print' a binary program before?)

A compromise that is used by many applications is to simply note
whether the output is being directed to a file (in which case no
^D is written) or to a device (in which case, a direct connection
to the printer is assumed and a ^D is written at the end of the
job.)

Note that on your hypothetical MS-DOS system (people don't really
use them, do they? *shudder*) `print' doesn't work anyway for text
files---perhaps the most commonly printed thing---so a `special
program' is needed anyway.

> Doug McDonald

-tom