tomwest@gpu.utcs.toronto.edu (Tom West) (01/22/88)
Since there have been a lot of requests for this, here is the fix for the
newest LaserPrep to get it to work on QMS and other printers. It is assumed
that you are already have gotten other LaserWriter/Prep combinations to work.
If there is trouble with that, mail me and I can send you a (v. long) article
on how to mix and match headers with mac generated PS files.
-----------------------------------------------------------------------------
The problem with the newest LaserPrep (Version 65)
--------------------------------------------------
(Used by LaserWriter driver Version 4.0)
----------------------------------------
This is a problem that surfaces on some versions of Postscript
interpreters. The symptoms are that no error messages are generated
and that no output is produced. The problem was found and diagnosed
by Terry Jones at the University of Toronto Computing Centre and
has several easy solutions.
Problem: The newest version 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 and if it finds that these exist, it
disposes of the code for these functions (the code is the hex at the
end of the file). Unfortunately, when hooked up on a serial line, it
disposes until it reaches a ^D, which ends up being the end of job
marker at the end of the users mac PS file. Hence the body of the
job gets thrown into the void. 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 mac 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 files.
The solutions to the problem of the LaserPrep is two-fold.
(1) If you are not using the code (i.e. you have 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 builtin 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 code so
that the laser printer will always use the code. This may not be
very efficient, but it guarantees that the code should work for all
manners of Postscript devices.
What follows is the original Apple LaserPrep file version 65. The
modification depends on which solution you want to use.
(1) Delete everything from line 487 (inclusive) to the end. Line 487 is
currentfile ok userdict/stretch known not and{eexec}{flushfile}ifelse
(2) Change line 487 from
currentfile ok userdict/stretch known not and{eexec}{flushfile}ifelse
to
currentfile ok userdict/stretch known not and pop true{eexec}{flushfile}ifelse
If there are any problems with this, please direct them to me.
--
Tom West
BITNET: tomwest@utorgpu.bitnet, tomwest@gpu.utcs.utoronto
Internet: tomwest@gpu.utcs.toronto.edu
UUCP: tomwest@utgpu
utzoo, yetti, harpo, mnetor \
cbosgd, deepthot, utoronto - !utgpu!tomwest
ihnp4, lsuc, sfmin, vnr-vpa /lamy@ai.toronto.edu (Jean-Francois Lamy) (01/23/88)
In article <1988Jan22.104342.19337@gpu.utcs.toronto.edu> tomwest@gpu.utcs.toronto.edu (Tom West) writes: >(2) Change line 487 from > >currentfile ok userdict/stretch known not and{eexec}{flushfile}ifelse > to >currentfile ok userdict/stretch known not and pop true{eexec}{flushfile}ifelse One also needs to do the same for smooth4 defined a bit later. Jean-Francois Lamy AI Group, Department of Computer Science lamy@ai.toronto.edu University of Toronto, Canada M5S 1A4 uunet!ai.toronto.edu!lamy