Re: Character encodings in PostScript driver

[Ethan M. <merritt@u.washington.edu>]

On Thursday 16 September 2004 02:43 am, Hans-Bernhard Broeker wrote:
> > The chief benefit from this is that new encodings could be
> > added without patching or rebuilding gnuplot from source;
> > you would just have to place an appropriately named file
> > in the path specified by some environmental variable,
> > e.g. GNUPLOT_PSFILES.
>
> The only problem I have with this is that we're slowly developing
> a rather huge and inconsistently named zoo of environment variables.
> I think before we add new ones, we should try to find a way of
> organizing them, and reducing their number.

That's a fair criticism.  But some of these environmental variables are
forced upon us by the support libraries, or by other operating system
components.  For example GDFONTPATH is required directly by libgd.
GNUPLOT_FONTPATH is our choice, but we really don't have much 
control over where the host operating system keeps its fonts.
What we certainly could do, however, is to revise the naming scheme
so that all environmental variables chosen by gnuplot itself begin with
a consistent string (GNUPLOT_ ).  For backward compatibility
we would have to create new names parallel to 
GNUTERMPATH GNUCOLORS GNUHELP FITSCRIPT GNUFITLOG

Hmm. That's not as long a list as I expected. 

> In particular, I think we really
> do need a mechanism that will provide defaults for all gnuplot path
> environment variables that are relative to the gnuplot Aexecutable's
> location, like GCC does it: it searches {bindir}/../include for headers,
> {bindir}/../lib for libraries, and so on, where {bindir} is whatever
> directory the GCC executable you're running found itself to sit.

That's fine with me, but it won't actually change many of the current
choices because most of them either (a) refer to directories used by
other system components or (b) require write access by the current user.