gar@cory.Berkeley.EDU (Gary D. Wong) (03/25/89)
Good morning netland. Being new to the postscript world, I am continually amazed with the capabilities of this language. But one point has continued to bother me. Can anyone suggest a good method of finding errors in postscript files? It seems to me that the only way to know if an error exists is if the file does not print. Besides using the interactive mode, does PS have any type of feedback that might lead to the soruce of the error? Thanks for the help. Gary D. Wong gar@cory.berkeley.edu // "It is better to remain silent \\ University of California, Berkeley << and thought a fool, than to >> (415) 642-9304 \\ open your mouth and confirm it" // Disclaimer: "Really Colonel Hogan, I see NOTHING, I see NOOOTHINNNNNG!"
izumi@violet.berkeley.edu (Izumi Ohzawa) (03/25/89)
In article <11401@pasteur.Berkeley.EDU> gar@cory.Berkeley.EDU (Gary D. Wong) writes: > Can anyone suggest a good method of finding errors in >postscript files? It seems to me that the only way to know if an error >exists is if the file does not print. Besides using the interactive mode, >does PS have any type of feedback that might lead to the soruce of the error? > If you are running the PostScript printer via its serial port, and can locate a spare CRT terminal, directly connect the terminal's serial input to the printer's 'stdout' pin. I forgot which pin, but it's either 2 or 3. You also need the pin-7 for the ground. With this, you can see all error and status messages that the printer generates. Frankly, I don't know why any of the PostScript printer manufacturers can't put a 5 line LCD display which show the last 5 lines of 'stdout' output right on the printer. In any case, you can use this display for debugging purposes more actively as if you sprinkle "printf()'s" in debugging C programs. This can be done by including, ...... your PostScript lines.... ( Before doing AAA.\n) print flush ... AAA ... ( After doing AAA.\n) print flush .... You get the idea. I can't do without it now. Izumi Ohzawa izumi@violet.berkeley.edu
crtb@nih-csl.UUCP (chuck bacon) (03/28/89)
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-4823don@brillig.umd.edu (Don Hopkins) (12/13/89)
In article <49400001@primerd> choinski@primerd.prime.com writes: > >||It seems like it might be possible, in principle, to get a cheap and >||accurate postscript previewer given you already have postscript in a >||printer. > >The hell with any pre-viewers! Does anyone out there have a postscript >lexer? I've just about had it with sending a large PS file to the >printer and find the entire job flushed because I misspelled "setgray". >And of course, it only reports one error at a time, so any additional >problems are found ONE AT A TIME! > >A PS-lexer would be great, and having a syntax checker as well would >be optimal. I don't need a full pre-viewer, just something to catch >simple errors. I can handle the semantic problems when I see the >output. > >Anyone have something that will do? > >-============================================================================- > Burton Choinski choinski@env.prime.com > Prime Computer, Inc. (508) 879-2960 x3233 > Framingham, Ma. 01701 > Disclaimer: Hey, not me man; musta been my evil twin. >-============================================================================- PostScript syntax is so trivial that most of the bugs you enounter are semantic. How could a mere lexer know that "setgary" was a user defined procedure rather than a typo, without actually interpreting the code? What you probably need is a PostScript interpreter with a stubbed-off graphics library. I'm not saying that such a beast (a graphics-less postscript interpreter) would not be useful (it would be very useful, and relativly easy to write). You could lexically analyze the document structuring comments, without actually interpreting the PostScript code, but no matter how badly formed the document structure is, it'll never cause any of the types of bugs you want to detect, since comments are ignored by the interpreter, of course! The best way to debug PostScript is on the screen. I have heard that Adobe sells some sort of PostScript debugging system for Display PostScript, but I have never seen it. (and I've only seen ads for LaserTalk.) I've written an extensive PostScript debugger for NeWS (The PSIBER Space Deck -- PostScript Interactive Bug Eradication Routines), that is described in a paper I presented at the Usenix Monterey graphics conference. I use it all the time, and it seemed to work last time I tried (it's been most useful for debugging itsself). If you'd like a copy of the paper and/or the source code to the NeWS PostScript debugger and associated paraphernalia, send me a note (don@brillig.umd.edu, ...!uunet!mimsy!don) and I'll try to email it to you. (It's pretty big, but it's free!). (I recently posted it all to comp.windows.news, so check there first if you can.) The NeWS debugger is written entirely in PostScript. It runs on NeWS 1.1 and X11/NeWS. It would be impossible to run it in a laser printer though, because of its extremely interactive nature (direct stack manipulation, graphical data structure editor, etc...). -Don