Re: Character encodings in PostScript driver

[Petr M. <mi...@ph...>]

> that any substantial fraction of them get hard-coded into gnuplot's
> PostScript terminal driver.

Fortunately there are only few supported until now.
That could change if we really want to support all possible encodings.

> I propose that we back out all of the in-line character encodings
> from post.trm, and instead have a general mechanism of loading
> any requested encoding from an external file.  If you recall, I
> coded up a simple patch to do this in the run-up to version 4
> because it was needed in order to reduce the total size of
> the terminal driver to the point it could be built for 16-bit DOS/Win.

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

I don't like new environmental variable. There is already GNUPLOT_LIB; and
also "set loadpath". That's enough.

> As I recall, the only real objection at the time was a fear that
> these external files containing the character encoding info
> would get lost under Windows because there is no standard
> directory in which to put such things.  I don't really have much
> sympathy with limiting gnuplot's options just because Windows
> is poorly designed.

We can also say the opposite: gnuplot is poorly designed because it does not
know where to put its files... That's what the installation program does
(but gnuplot does not have it).

But that's simple: that ps header file should be in the same directory as
gnuplot executable, or in GNUPLOT_LIB, or gnuplot_loadpath.

Thus its search should be that one already implemented for any other OS,
i.e. on Windows, DOS, OS/2 you must replace "/usr/(local/)lib/" by "<dir of
gnuplot exefile>".

---
PM