🚀 go-pugleaf

In article <1dmj7eINNha9@gap.caltech.edu> carl@SOL1.GPS.CALTECH.EDU (Carl J
Lydick) writes:
>In article <BxGFon.27D@tegra.com>, rothman@tegra.com (Steve Rothman) writes:
>=What I would like my mythical "ps dissasembler" program to do is to replace
the
>=line 
>=
>=4 s
>=
>=with a line reading
>=
>=4 dup mul
>=
>=Then I know exactly what's happening, without prolonged searching around in
the
>=prolog!
>
>Sorry.  Can't be done.  Consider the following (legal) Postscript code:
>
>	/BIG
>	{ /POINTSIZE 18 def
>	} def
>	/SMALL
>	{ /POINTSIZE 9 def
>	} def
>	BIG
>	/Courier findfont POINTSIZE scalefont setfont
>	72 72 moveto
>	(This is the big font) show
>	SMALL
>	/Courier findfont POINTSIZE scalefont setfont
>	72 144 moveto
>	(This is the small font) show
>	showpage
>
>Now, how would your "disassembler" expand POINTSIZE?

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... 

By the way, maybe a better analogy to what I want (rather than "dissasembler")
is a C preprocessor that can take a C program, with all kinds of #defines,
#includes, and various conditionals, and turn in into straight C code. This
kind of utility I think is always included with C compilers, probably because
it's a step that is done automatically during normal compilation 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? 
==================================================================
Steve Rothman, Tegra Inc, Billerica Massachusetts USA
email: rothman@tegra.com *** CIS: 72120,2747 *** FAX: 508-663-7082