Re: pm3d for emf terminal and point types

[<tim...@en...>]

Dr. Johannes Zellner a =C3=A9crit :
> On Wed, Dec 13, 2006 at 07:19:12PM +0100, Timoth=C3=A9e Lecomte wrote:
>  =20
>> Dr. Johannes Zellner wrote:
>>    =20
>>> ...
>>> 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.
>>>  =20
>>>      =20
>> UTF-8 and UTF-16 are just two differents encoding schemes for Unicode,=
=20
>> i.e. the same range of characters.
>> iconv can convert from UTF-8 to UTF-16 without losing anything.
>>    =20
>
> 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 '=C3=A4=C3=B6=C3=BC =C3=84=C3=96=C3=9C =C3=9F =E2=82=82=C2=
=B2=E2=82=83=C2=B3=E2=82=84=E2=81=B4=E2=82=85=E2=81=B5=E2=82=86=E2=81=B6=E2=
=82=87=E2=81=B7=E2=82=88=E2=81=B8=E2=82=89=E2=81=B9 =C2=BD =C2=BE =C2=BC =
=E2=82=AC'
>
> (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.
>  =20
According to wikipedia: "In computing, UTF-16 (16-bit Unicode=20
Transformation Format) is a variable-length character encoding for=20
Unicode, capable of encoding the entire Unicode repertoire." So, if=20
superscript 1 to 9 are defined in Unicode, they should be available in=20
UTF-16. As usual, there may be a bug or a limitation in some part of the=20
conversion process...

> I believe that =C2=B5 and =CE=BB (also =CF=83) are implemented both in =
UTF-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.
>  =20
Agreed.
>  =20
>>> This gives me the idea of rather having a terminal independent recode
>>> option like
>>>
>>>     set recode "from encoding" "to encoding"
>>>
>>>  =20
>>>      =20
>> I agree with Ethan: I would rather use the locale mechanism to determi=
ne=20
>> the input encoding, deprecate the 'set encoding' command.
>> Then I would make gnuplot depend on iconv, and each driver could use=20
>> iconv facility to translate from the locale to its preferred format.
>>    =20
>
> 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.
>  =20
Ok, I spoke too early there about the locale thing. But the idea to use=20
iconv remains.

Best regards,

Timoth=C3=A9e