Re: Character encodings in PostScript driver

[Hans-Bernhard B. <br...@ph...>]

On Wed, 15 Sep 2004, Ethan Merritt wrote:

> They are all perfectly legitimate, but I think it is totally
> unreasonable that any substantial fraction of them get hard-coded into
> gnuplot's PostScript terminal driver.

My feelings about this issue aren't quite that strong, but in general I
agree with this.

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

> I don't really have much sympathy with limiting gnuplot's options just
> because Windows is poorly designed.

OTOH, Windows users do form a serious share of the user base, and they
would complain rather loudly, and with some justification, too, if we just
broke Windows deliberately.  We have to at least make a serious effort to
support Windows to the extent possible.  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.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.