🚀 go-pugleaf

Here's my 2 cents' worth:

* The Laser Prep definitions are there to ease the job of translating
  graphics (including text) from the QuickDraw mindset to the
  PostScript mindset. To do this, they add another level of interpretation,
  on top of PostScript, which is already interpreted.
* They also include a number of eexec's--3 in the 5.2 version of
  Laser Prep: one which redefines the "tonerlight" operator on
  LaserWriter NT's (fix for a ROM bug?), and two more to define
  Apple's special bitmap stretching and smoothing operators. The
  worst thing about these eexec's is what the check that the preceding
  PostScript code does if it finds these are already defined:
  it simply does a "flushfile", which causes the entire rest
  of your print job to be ignored. This really only causes a
  problem a) if a Mac user has already done a print job to that
  printer, which means that Laser Prep is already loaded, and b)
  your printer interface software isn't smart enough to check for
  the presence of Laser Prep itself.
      I managed to hack the code about to do a "readstring" and
  eexec from that, rather than direct from "currentfile" (so that
  I could just discard the string if the operator was already defined),
  but that required getting the length of the readstring exactly right.
      Also, those hex characters are stored as a few *extremely*
  long lines. This may cause problems with software which is trying
  to process the PostScript a line at a time.
* The Mac LaserWriter driver was never designed to produce encapsulated
  PostScript (after all, how would you handle a multiple-page print job?).
  If you're trying to turn Mac PostScript output into an EPS file, I wish
  you luck.

By the way, I don't understand this business about requiring "<" and ">"
brackets on the hex input to "readhexstring": I just tried talking
to one of our LaserWriters over an RS-232C line, and readhexstring
works just fine without the "<" and ">".

It's not needed on readstring either; my hacked Laser Prep gets
away without it just fine--also over RS-232C lines.

Lawrence D'Oliveiro
Computer Services Dept                    fone: +64-71-562-889
University of Waikato                      fax: +64-71-384-066
Hamilton, New Zealand            electric mail: ldo@waikato.ac.nz
It's a commentary on the state of the industry when the breakthrough
is seen to be, not getting an idea to work, but getting it to work
under Unix.