[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnuplot-info-beta
Subject:    Re: pm3d for emf terminal and point types
From:       Timothée Lecomte <timothee.lecomte () ens ! fr>
Date:       2006-12-13 20:40:42
Message-ID: 4580654A.9060707 () ens ! fr
[Download RAW message or body]

Dr. Johannes Zellner a écrit :
> 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.
>   
According to wikipedia: "In computing, UTF-16 (16-bit Unicode 
Transformation Format) is a variable-length character encoding for 
Unicode, capable of encoding the entire Unicode repertoire." So, if 
superscript 1 to 9 are defined in Unicode, they should be available in 
UTF-16. As usual, there may be a bug or a limitation in some part of the 
conversion process...

> 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.
>   
Agreed.
>   
>>> 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.
>   
Ok, I spoke too early there about the locale thing. But the idea to use 
iconv remains.

Best regards,

Timothée


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
gnuplot-beta mailing list
gnuplot-beta@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

[prev in list] [next in list] [prev in thread] [next in thread]