Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!sunic!liuida!andwi
From: andwi@ida.liu.se (Andreas Wickberg)
Newsgroups: comp.lang.postscript
Subject: Re: Bind problems
Message-ID: <1991May6.102742.4180@ida.liu.se>
Date: 6 May 91 10:27:42 GMT
References: <1991May5.010114.24826@neon.Stanford.EDU> <488@heaven.woodside.ca.us>
Organization: CIS Dept, Univ of Linkoping, Sweden
Lines: 33

In article <488@heaven.woodside.ca.us> glenn@heaven.woodside.ca.us (Glenn Reid) writes:
>Maybe it's not "bind" that's at fault, but for people (like me) to
>recommend using "load" to tie an operator directly to a user name.
>Perhaps you shouldn't do that unless you're quite sure the name is
>likely to be unique.

I don't agree. If the idea of EPS-files should work, both sides must cooperate.
Since there are a lot of programs out there already, new programs must add
some extra protection both when importing and exporting.
The current bind problem should be solved by 'declaring' variables before
they are used. For example,

/s /show load def
...
/s () def
/m {
	/s exch def s show
} bind def

This is not too much work once you get used to it.
The importing program should also take some actions. The most common
is to have a special dict that contains all the 'loaded' operators, and
use a unique name for this dict in userdict. As a bonus you will avoid some
dict overflows (when you use the Macintosh PrintManager you will run inside
the md dict, not userdict, and this might have a quite small extra
space sometimes.) Of course, your special dict will only be on the dict-stack
for you own routines, when importing an EPS you might instead
push a dict that redefines some operators (for color separations), and
then push userdict.
When you get all this to work, try to import and color separate an EPS-file
created in your own program...

Andreas