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