loki@physics.mcgill.ca (Loki Jorgenson Rm421) (07/18/90)
Is there a "lint"-like parser for PostScript which will check for and identify syntax errors in a PS file? Preferably Public Domain, of course. Thanks, Loki Jorgenson node: loki@physics.mcgill.ca Physics, McGill University fax: (514) 398-3733 Montreal Quebec CANADA phone: (514) 398-6531
zwicky@itstd.sri.com (Elizabeth Zwicky) (07/21/90)
In article <10035@brazos.Rice.edu> loki@physics.mcgill.ca (Loki Jorgenson Rm421) writes: >Is there a "lint"-like parser for PostScript which will check for and >identify syntax errors in a PS file? Preferably Public Domain, of course. This is one of the two classes of questions that people ask frequently on comp.lang.postscript that indicate a fundamental misconception about PostScript. (The other class has as its worst example "Does anyone have a PostScript to ASCII translator" and indicates a much *worse* fundamental misconception.) The problem here is that almost all of the interesting part of PostScript is semantics, not syntax. The only syntax rule states that unquoted parentheses may not occur inside strings. (It is legal, if unadvisable, to end a file without closing open delimiters.) The number of true syntax errors people make is vanishingly small, and they're all easy to catch. Even throwing in a check for delimiter-matching doesn't help much, since delimiters can legally and logically be crossed (i.e. it is possible to have a reasonable program which mixes delimiters like this: { (}) [} {(]) ] (}) }, without quoting them, which is going to drive anything that tries to match delimiters via pure syntactic rules straight up a wall.) In short, lint for PostScript is a) trivial and b) worthless. What you need instead is an interactive debugging environment, to let you get a handle on the semantics. If you're programming a printer, this is a real problem; if you're programming a display, you should be able to find some such tool. (Actually, I tend to debug printer code on a display, for this reason.) ELizabeth