🚀 go-pugleaf

In article <186@heaven.woodside.ca.us> glenn@heaven.UUCP (Glenn Reid) writes:

> What you really want the shell script to do is not to expand the
> procedure calls back into raw PostScript, but to eliminate procedure
> definitions from the prologue that are not called at all.  Although
> applications could keep track of what was drawn and write out a different
> prologue accordingly, that's not very practical all of the time.

I could see initally writing an application to keep track of which parts
of the prolog were actually used, but if you let the prolog procedures
call each other it could be a maintenance nightmare keeping the
caller/callee matrix updated.

On the other hand, this is EXACTLY the problem most linkage-editors deal
with every day and by and large this is a known technology.  Sure is true
that there is nothing really new under the sun...

If the Illustrator prolog is always exactly the same, why bother to write
it out into the save file at all?  I assume it is utterly ignored when a
file is read in.  Then provide a separate program or a menu function to
write "a *complete* postscript file", including the prolog.

BTW, is it really true that you can save execution time by using prolog
procedures rather than the "raw" lineto, curveto, etc primitives?  Seems to
me there's always got to be SOME intepreter overhead hit, and since the
numbers always change you're not saving string-to-num time.  Can it really
cost so much to lookup "lineto"?

Actually, assuming a one-for-one l == lineto c == curveto then there is
exactly one lookup in either case.  So is there any runtime saving, or are
you in fact trading runtime away for space with this simple-minded prolog?

Just random thoughts -- PostScript sure is a neat toy!

-- 

Ben Cranston <zben@umd2.umd.edu>
Warm and Fuzzy Networking Group, Egregious State University
My cat is named "Perpetually Hungry Autonomous Carbon Unit"; I call him "Sam".