Re: i18n + widechars

Thomas Dickey <[email protected]>
Newsgroups gmane.network.tin.devel
Message-ID <[email protected]>
On Wed, 6 Apr 2005, Michael Bienia wrote:

> On 2005-04-06 13:40:23 +0200, Urs Janßen wrote:
>> In <[email protected]>, Urs Janßen wrote:
>>>> I can't reproduce it in my normal utf-8 environment. Do you have some
>>>> more information about how to reproduce it?
>>>
>>> not really. my normal env. is a non utf-8 env. I started a new shell in
>>> an xterm via
>>> xterm -u8 -fn "-Misc-Fixed-Medium-R-Normal--18-120-100-100-C-90-ISO10646-1"
>>> and set the floowing locales:
>>> LC_CTYPE=de_DE.utf-8
>>> LC_MESSAGES=de_DE.utf-8
>>> tin was linked against libncursesw and I got the 'grabbled' output.
>>
>> /s/libncursesw/libncurses - the problem only shows up if linked
>> against libncurses, not if linked against libncursesw.
>
> I assume this is a problem within libncurses. If I let tin print the
> complete string (options_menu.c::311) also to stderr I get there the
> expected result: all ':' are in one column.

It's not a "problem", but a limitation.

UTF-8 locales are designed for storing more than 8-bits worth of 
information in a cell.  The line-drawing characters for instance do that. 
Depending on how old the libncurses is, it will/won't have some code to 
make it do the expected thing with line-drawing characters.

(ncurses 5.4 has some fixes for this, and I made other fixes after 5.4
which some distributions have packaged).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.