Filter
Top Products
POSTSCRIPT
2-14 XEROX DOCUPRINT NPS GUIDE TO USING PAGE DESCRIPTION LANGUAGES
Control-D as binary data and end-of-job
The fact that control-D can be a valid PostScript end-of-file (EOF)
delimiter in one communications protocol and invalid in another
creates a paradox for PostScript printers that must accept jobs
created for either communications mode without any indication of
which communications mode was used. The recommended solution
is described in “Solution to control-Z and control-D problems.“
How PostScript jobs are delimited—separated from each other in a
continuous stream of jobs—is not simple. Remember that the actual
PostScript interpreter has no concept of a job. There is no PostScript
job end operator. The job server, which is external to the interpreter,
must make the job begin and job end determination and act
accordingly. It does this by considering a PostScript job to be a
simple byte stream input file. When end-of-file (EOF) is reached, the
job server restores the PostScript state for the next input file (job).
The way input files—or jobs—are sent to a PostScript printer
depends on the communications protocol used to transfer the
PostScript document to a PostScript printer. For example, when a
LaserWriter is connected to an Apple Macintosh over the AppleTalk
serial communications channel, AppleTalk protocol encapsulates
PostScript jobs as files. The LaserWriter AppleTalk software delimits
PostScript jobs based on the AppleTalk file protocol. AppleTalk
encapsulates files in its own high-level protocol. This allows
AppleTalk to support transparent data transmission; that is, there are
no byte codes reserved for AppleTalk communication functions. This
means that all byte values are valid in a PostScript master.
This is not true when you are connecting an IBM PC to a LaserWriter
over the LaserWriter asynchronous serial communications (RS232
or RS422). There is no high-level protocol, such as AppleTalk has,
that delimits files, so the control-D character code (octal 004) was
chosen to delimit input files. The LaserWriter asynchronous software
handler strips out the control-Ds and sends an EOF to the PostScript
job server. This prevents sending binary PostScript jobs (jobs where
all byte codes are valid PostScript data) through the asynchronous
serial communications port. In contrast, the LaserWriter can accept
binary PostScript jobs over AppleTalk since it is data transparent.
Control-Z and superfluous errors
Control-Z is not used by the LaserWriter RS232 asynchronous serial
communications software; yet it often appears at the end of many
PostScript masters and can pose problems.
Control-Zs appear at the end of many PostScript files created under
the Microsoft Disk Operating System (MS-DOS). They cause errors
on a LaserWriter, but this is usually unnoticed because the control-Z
undefined command error occurs after the last page is printed. In
addition, because the default error handling mode of the LaserWriter
is to send the error back to the creator through the communications
port, most users never see the error. This is not the case for
PostScript products that have been configured to print a break page
on every error.
Because the majority of the error messages caused by control-Z are
superfluous, it is recommended that control-Zs used as end-of-files
be ignored.