🚀 go-pugleaf

The easiest way I know of to debug PostScript programs is to use Kermit on
a PC.  Process the words wherever you like, get the .ps file to the PC, and
use Kermit to Transmit the file.  Details:
1. Wheedle, deal and steal as needed, to gain access to the printer's
  serial port via a PC-to-printer link.  This is so valuable that any other
  substitute, even Glenn Reid's errorhandler.ps, fades in comparison.
2. Run MS-Kermit, and optionally ask it to log the session.  The log file
  will contain the echo of the downloaded .ps file as well as error messages.
3. With Kermit in `connect' mode, talk to the printer, and get it to echo
  and talk back with the `executive' command.  Precede with a ctrl-D to
  assure that the printer isn't intentionally ignoring you.
4. Now that you can see what you're typing and the printer responds, learn
  the use of '=', '==', 'print', 'pstack' and related debugging commands.
  Enter some simple program by hand, to verify you're really in touch,
  for example:    /FontDirectory {pop ==} forall
  will type out the names of all 35 (or howevermany) fonts.
5. With the printer's prompt waiting, back off into MS-Kermit, and tell it
  to     transmit myfile.ps
  where myfile.ps is an ordinary postscript file.  You'll see it echoing.
  The trick is that MS-Kermit by default waits for the CR before sending
  each next line, so there's no danger of a data overrun.
6. When you see a PostScript error message rolling up your screen, hit
  ctrl-S or ctrl-C and see what it says.  The error message will appear
  right after the input line which triggered it.
7. If you've lost PostScript (it's decided to ignore you until EOF), you'll
  have to debug by scrolling Kermit back and guessing.

Failing this approach, do load Glenn Reid's ehandler.ps (which appears
in comp.lang.postscript every once in a while), and celebrate as it not
only prints onto the paper an error message, but also prints the image
which otherwise would have been lost.  It's wonderful!  --But, it
interferes a bit with the interactive debugging technique unless you're
on a truly liberal paper budget.
	Chuck Bacon, crtb@alw.nih.gov (Internet), crb@nihcudec (Bitnet)-- 
crtb @ dxi.nih.gov, crtb @ alw.nih.gov, crb @ nihcudec (Bitnet), (301)496-4823