Filter
Top Products
PostScript
Guide to Using Page Description Languages 1-17
Color differences on full color and highlight color printers
The output of a job printed on a highlight color printer is likely to
appear different from the output of the same job printed on a full
color printer, even if the job uses only one color. This occurs
because the color on the highlight printer is limited to the color
toner used, plus black, whereas the full color printer toners can
mix to produce millions of different colors. To adjust the output
color in the job when printing on a different type of printer, you
must change the application.
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.