From: rothman@tegra.com (Steve Rothman)
Newsgroups: comp.lang.postscript
Subject: Re: PostScript disassembler?
Date: 11 Nov 92 15:10:10 GMT
Organization: Tegra, Inc.

In article <1dpgbiINNnss@gap.caltech.edu> carl@SOL1.GPS.CALTECH.EDU (Carl J
Lydick) writes:
>In article <BxIEBK.BC1@tegra.com>, rothman@tegra.com (Steve Rothman) writes:
>=Well, I guess I would want it to replace POINTSIZE with 18 in the first
>=instance and 9 in the second. Somehow, a PostScript interpreter can deal with
>=this.  Maybe you mean to say that the program I'm looking for is just as
>=complex as the parsing machinery used by a PS interpreter (which is way
beyond
>=me). But "can't be done" seems a little strong... 
>
>Can't be done IN A DISASSEMBLER.  What you're asking for is a PostScript
>INTERPRETER with a trace capability.  Of course, there's no way of telling a
>priori whether or not the output of this interpreter will be finite for any
>given postscript file :-).
>
In the realm of PS files output by typical applications on standard platforms,
what would create infinite output?  I understand the output might be much
longer, but infinite?...

>=anyway.  Perhaps "preprocessing" is also a step that PS interpreters also
have
>=to do anyway. In that case, might not a PS interpreter allow this as an
>=option?
>
>I believe they do the evaluations on the fly, rather than generating the HUGE
>amounts of code that would be required if they tried to "preprocess" things
>then execute them.  Yes, an interpreter *COULD* be written which has a trace
>capability.  But it would not, in any reasonable sense of the word, be either
a
>"disassembler" or a "preprocessor."

Well, I honestly have no idea what an appropriate name would be for the program
I'm looking for, and my attempts at naming it may well betray my lack of
understanding of the actual process that would be involved. I have no
experience with GhostScript, but could it be modified to show some sort of
"trace"?

I don't want to get hung up on semantics, so maybe I could just restate my
quandry: I am given a PS file, produced by an application (NOT hand-coded),
that is not doing the right thing on a particular machine.  For instance,
perhaps type is coming out at 10 pt instead of 20 pt. I find the section of
code that "shows" the string in question, only it's not using the show or
scalefont operators.  When I examine the code, it's using specially defined
operators, which are themselves based on other specially defined operators,
which in turn are based on other operators, ad nauseum. I cannot look up any of
these customized operators and procedure names in any book. If I spend 30
minutes, or an hour, or a day poking through the prolog, finding out what is
defining what, I can eventually understand exactly what's going on, and why the
type is coming out at the size that it is. I'm just looking for an automatic
way to turn "myfunnyoperator anotherfunnyoperator thisisajokeright (String in
Question)" into "standard" postscript, some of which I know, and the rest of
which I can look up in my trusty Red Book. 

BTW, I'm not criticizing the use of redefined operators, procedures, etc.: I
know they add efficiencies to the process in many ways. They just make it a
nuisance to debug PS generated by someone else's application!

==================================================================
Steve Rothman, Tegra Inc, Billerica Massachusetts USA
email: rothman@tegra.com *** CIS: 72120,2747 *** FAX: 508-663-7082
Newsgroups: comp.lang.postscript