🚀 go-pugleaf

rothman@tegra.com writes:
>Sometimes self-contained, perfectly functional PS programs get pretty hard
>to decipher, because a lot of procedure definitions are made, operators are
>redefined, etc. Does anyone know of a program that could eat a legal, but 
>cryptic PS program and spew out Red Book standard PS?...

It's not clear what you mean by "Red Book standard"--if it's a legal
program, it's "red book" by some plausible definition.  Green book...now,
that would be a help.

Unwinding procedures is a hard one, because you've got recursion and
dynamic binding.  Even if you don't try to unwind any recursive procedures,
it seems that expanding them out might well make a program harder to read
rather than easier.

Operator redefinitions can be found; this is something an interpreter could
be made to do with a little rewiring.

Why don't you sketch out some examples for us--original program and what
you'd like as the result of the processing?  That might make it easier to
get a handle on the problem.

>...Obviously, the
>output would be far larger than the input, but possibly it might be easier to
>debug...

Is your goal really more at a PostScript debugger?  If that's what you're
after, let's take that tack instead.

>PS: Icing on the cake would be a pretty-print formatter, if this isn't
>too ridiculous for PostScript. (Is there such a thing as pretty PS?)

Well, there's definitely such a thing as ugly PS!  But yes, it's not hard
to derive rules for formatting PS according to a style like the one the
green book uses.
-- 
Dick Dunn    rcd@raven.eklektix.com   -or-   raven!rcd    Boulder, Colorado
	...Simpler is better.

In article <1992Nov8.061155@eklektix.com> rcd@raven.eklektix.com (Dick Dunn)
writes:
>rothman@tegra.com writes:
>>Sometimes self-contained, perfectly functional PS programs get pretty hard
>>to decipher, because a lot of procedure definitions are made, operators are
>>redefined, etc. Does anyone know of a program that could eat a legal, but 
>>cryptic PS program and spew out Red Book standard PS?...
>
>It's not clear what you mean by "Red Book standard"--if it's a legal
>program, it's "red book" by some plausible definition.  Green book...now,
>that would be a help.

I guess what I mean is using the core Red Book operators, not invented or
redefined ones. Sure it's legal to redefine and create new operators, (and
often a great idea for efficiency) but if
I'm trying to understand a bit of PS code that has the operator "xybabble" in
it, I can't look that up in the Red Book. Of course, I _can_ look in the
begining of the PS to see how "xybabble" is defined, but I'm always running
into the situation while "xybabble" turns out to be a procedure using "xfoo"
and "ybar", and then I need to look those up, and they of course use other
redefined operators/procedures, and so on. If prologs were completely commented
& structured, this wouldn't be a big problem, but typically they're not!

>
>Unwinding procedures is a hard one, because you've got recursion and
>dynamic binding.  Even if you don't try to unwind any recursive procedures,
>it seems that expanding them out might well make a program harder to read
>rather than easier.

I'm sure you're right, but there's no harm in "expanding" them, because if they
do get more confusing I can always look at the original <g>!

>
>Why don't you sketch out some examples for us--original program and what
>you'd like as the result of the processing?  That might make it easier to
>get a handle on the problem.
>

Well, here's an extremely simple-minded example:

:
:
%buried somewhere in the prolog
/d {dup} def
:
%buried somewhere else in the prolog
/m {mul} def
:
%buried in yet another place in the prolog
/s {d m} def    
:
:
%somewhere deep in the page description
4 s
:
:

Ok, so I'm trying to understand why something happened on a page. The line, "4
s" happens right before something is drawn. In order to find out what it does,
as I'm looking in the page description, I can search for "/s". When I find it,
I then have to do a search for "/d" and "/m".  Since this is a simple example,
I'm now set. In real-life, I've found my self backtracking through a dozen
layers, in many directions, just to find out what one lousy operator in the
middle of an otherwise understandable page description does.

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!

>
>>PS: Icing on the cake would be a pretty-print formatter, if this isn't
>>too ridiculous for PostScript. (Is there such a thing as pretty PS?)
>
>Well, there's definitely such a thing as ugly PS!  But yes, it's not hard
>to derive rules for formatting PS according to a style like the one the
>green book uses.
>-- 
>Dick Dunn    rcd@raven.eklektix.com   -or-   raven!rcd    Boulder, Colorado

So, is there a Pretty Printer anywhere?

Thanks for any ideas.

==================================================================
Steve Rothman
email: rothman@tegra.com *** CIS: 72120,2747 *** FAX: 508-663-7082

In article <BxGFon.27D@tegra.com>, rothman@tegra.com (Steve Rothman) writes:
=Well, here's an extremely simple-minded example:
=
=:
=:
=%buried somewhere in the prolog
=/d {dup} def
=:
=%buried somewhere else in the prolog
=/m {mul} def
=:
=%buried in yet another place in the prolog
=/s {d m} def    
=:
=:
=%somewhere deep in the page description
=4 s
=:
=:
=
=Ok, so I'm trying to understand why something happened on a page. The line, "4
=s" happens right before something is drawn. In order to find out what it does,
=as I'm looking in the page description, I can search for "/s". When I find it,
=I then have to do a search for "/d" and "/m".  Since this is a simple example,
=I'm now set. In real-life, I've found my self backtracking through a dozen
=layers, in many directions, just to find out what one lousy operator in the
=middle of an otherwise understandable page description does.
=
=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?
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.

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

In article <BxIEBK.BC1@tegra.com>, rothman@tegra.com (Steve Rothman) writes:
=In article <1dmj7eINNha9@gap.caltech.edu> carl@SOL1.GPS.CALTECH.EDU (Carl J
=Lydick) writes:
=>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... 

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

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

No, that's *STILL* a bad analogy.  If you apply the C preprocessor to a finite
C program, the result is guaranteed to be finite.  Not so in your mythical
disassembler.  It's easy to write a PostScript program that never stops.  You
need a PostScript interpreter, not a "disassembler."

=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?

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."
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.

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