Re: pm3d for emf terminal and point types

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

On Wednesday 13 December 2006 12:48 pm, Dr. Johannes Zellner wrote:
> On Wed, Dec 13, 2006 at 07:19:12PM +0100, Timoth=C3=A9e Lecomte wrote:
> > Dr. Johannes Zellner wrote:
> >
> > UTF-8 and UTF-16 are just two differents encoding schemes for
> > Unicode, i.e. the same range of characters.
> > iconv can convert from UTF-8 to UTF-16 without losing anything.
>
> no. That's not true as far as I know.

Timoth=C3=A9e is correct. UTF-8 and UTF-16 are alternative schemes to index
exactly the save Unicode tables. So they both encode exactly the same
range of characters.

> I believe that =C2=B5 and =CE=BB (also =CF=83) are implemented both in UT=
=46-8 and
> UTF-16, but only =C2=B5 is implemented in latin1 so it makes sense to
> implement more than latin1 for the emf terminal.

Huh? Neither =CE=BB nor =CE=BC is contained in the latin1 character set.
There's =C3=9F, which looks sort of beta-ish but isn't really. That's as
close as you can get to Greek characters in latin1.

> I completely disagree. As pointed out in another email, gnuplot input
> scripts should be portable and not rely on some locale setting. I use
> for example latin1 for gnuplot input scripts as this produces the
> correct output in postscript but on the other hand my locale is set
> to UTF-8.=20

Are you sure your scripts are in latin1?  How do you type them in
latin1 if your locale is set to UTF-8?  Remember that latin1 is
isomorphous to Unicode code pages 0 and 1, so I am not sure you
have tested a real distinction.

> A file encoding has nothing to do with the user's locale.=20

A file's *claimed* encoding can be anything you tell it,
but that does not guarantee that the contents actually match the
claimed encoding.  That is what I see as the fatal flaw in gnuplot's
current "set encoding" command.  It doesn't really change the=20
encoding for any terminal that I know of.  All it does is stick
a header or other label in the output file that *claims* such-and-such
an encoding is being used.

If I, sitting at a gnuplot session on my UTF-8 terminal,=20
type "set encoding cp852" and then type in a bunch of non-ascii
characters, any output file I produce will be internally inconsistent.
It will claim at the top that it is cp852, but the actual contents
will be UTF-8.   That's why I want to deprecate the "set encoding"
command.  It does not really set the encoding, it just provides
instructions to some other program, and those instructions may or
may not be correct. It would be better to enforce consistency
by specifying the actual current encoding in the output file,
as taken from the current locale.
=20


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA