Re: pm3d for emf terminal and point types

[Dr. J. Z. <joh...@ze...>]

On Wed, Dec 13, 2006 at 07:19:12PM +0100, Timothée Lecomte wrote:
> Dr. Johannes Zellner wrote:
> > ...
> > well, I had a quick look at unicode for emf. Apparently emf can only do
> > UTF-16 (little endian). Implementing this is really easy when using
> > iconv to convert to UTF-16LE. The drawbacks are:
> >
> > 1. will loose some characters, e.g. when converting UTF-8 to UTF-16.
> >   
> 
> 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. There are for example 3-byte UTF-8
characters like sub/superscript 1 - 9 and I belive only subscript (or
superscript?) 2 and 3 are available in UTF-16. Can you read this:

    set title 'äöü ÄÖÜ ß ₂²₃³₄⁴₅⁵₆⁶₇⁷₈⁸₉⁹ ½ ¾ ¼ €'

(The mail should be utf-8 encoded). Try to convert it to UTF-16 and
you'll loose some of the characters. At least this is what I observed
when using iconv.

I believe that µ and λ (also σ) are implemented both in UTF-8 and
UTF-16, but only µ is implemented in latin1 so it makes sense to
implement more than latin1 for the emf terminal.

> > This gives me the idea of rather having a terminal independent recode
> > option like
> >
> >     set recode "from encoding" "to encoding"
> >
> >   
> I agree with Ethan: I would rather use the locale mechanism to determine 
> the input encoding, deprecate the 'set encoding' command.
> Then I would make gnuplot depend on iconv, and each driver could use 
> iconv facility to translate from the locale to its preferred format.

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. A file encoding has nothing to do with the user's locale.

-- 
Johannes