There is a problem with Apple LaserPrep that surfaces on later versions of
PostScript interpreters (version 5.0 and newer). The symptoms are generally
that no error messages are generated and that no output is produced.
The newer versions of the LaserPrep implements a number of smoothing functions
that are present in some versions of Postscript interpreters. The LaserPrep
header checks for the existence of these functions in the interpreter. If it
finds that such funtions exist, it disposes of the code for these functions
(the code is the hexidecimal at the end of the file).
Unfortunately, when hooked up serially, the LaserPrep disposes of code until it
reaches a Control-D, which ends up being the end-of-job marker at the end of
the users PostScript file. Hence, the body of the job gets thrown away along
with the rest of the header.
On a laser printer where these functions don't exist, the code is used, and the
LaserPrep should function correctly.
A quick way of determining whether the Macintosh PS file needs this version of
the LaserPrep file is to check the first line, which should read:
!PS-Adobe-2.0
Other versions have different headers and use different LaserPrep file version
numbers.
The solution to this LaserPrep problem is two-fold.
(1) If you are not using the code (that is, if you have something like a QMS
printer), then you can delete the code entirely. This has the advantage of
making the LaserPrep file smaller and thus quicker. The disadvantage is
that if you add devices that don't have the built-in functions, you will
have to either use two different version of the LaserPrep file, or revert
to the second method.
(2) The second method consists of a very small change in the LaserPrep code so
that the laser printer will always use the smoothing code. This may not be
very efficient, but it guarantees that the code should work for most
Postscript devices.
The solutions that follow concern Apple LaserPrep file version 68, generated by
LaserWriter driver version 5.2. Which modification you use depends on which
solution you prefer.
Solution #1:
Delete everything from the line shown below, to the end of the header file.
This line is the last line of text immediately preceding the first section of
hexidecimal code (if you are using MacWrite to view the PostScript file, it's
about 12 pages in). The end of the header file can be located by finding the
line that says "%%EndProcSet". Do not delete the "%%EndProcSet" line. It must
remain to indicate the end of the header.
currentfile ok userdict/stretch known not and{eexec}{flushfile}ifelse
Solution #2:
Change the line located just above the first set of hexidecimal codes from:
currentfile ok userdict/stretch known not and{eexec}{flushfile}ifelse
to
currentfile ok userdict/stretch known not and pop
true{eexec}{flushfile}ifelse
Locate a second line of text after the long series of zeros, which follows the
first section of hexidecimal codes, and immediately before another section of
hexidecimal code.
Change the line located just above the second set of hexidecimal codes from:
currentfile ok userdict/smooth4 known not and{eexec}{flushfile}ifelse
to
currentfile ok userdict/smooth4 known not and pop
true{eexec}{flushfile}ifelse
LaserWriter Driver 5.1 will generate header files with a version number of 65.
Earlier driver versions will have smaller numbers. This information should
remain good as long as the second line of the actual PostScript file reads %!
PS-Adobe-2.0., as described above. If this version number changes, the location
of the lines to be changed may also differ, and there may be other lines that
need to be changed as well.
If UNIX, or A/UX, is used to look at these Command-K generated PostScript
files, the facility exists to number the lines of the file. The two lines that
need to be changed are 487 and 534.