Sorry I originally replied off-list to Bruno because the list mail was slow coming thru and I thought he was just mailing me in private..
On Mon, Oct 16, 2006 at 05:38:45PM -0700, Ben Wiley Sittler wrote: > just tried this in a few terminals, here are the results: > > GNOME Terminal 2.16.1: > U+0D30 U+0D4A displayed with width 3 > U+0D30 U+0D46 U+0D3E displayed with width 3 > NOTE: displays very differently in each case > > Konsole 1.6.5: > U+0D30 U+0D4A displayed with width 3 > U+0D30 U+0D46 U+0D3E displayed with width 4 > NOTE: displays very differently in each case > > mlterm 2.9.3: > U+0D30 U+0D4A displayed with width 2 > U+0D30 U+0D46 U+0D3E displayed with width 2 > NOTE: displays identically in each case As we can see, _none_ of these agrees with the current wcwidth implementation. In fact I'm pretty sure they all ignore wcwidth and use their own (possibly font-specific) interpretation of width, which fundamentally dooms the terminal from being able to be used for anything with columns or cursor positioning. If they don't even agree with the current wcwidth, and the current wcwidth cannot reasonably be used for Indic scripts, I see no good reason why wcwidth tables shouldn't be fixed to at least match values that _could_ be used for reasonable rendering... > >What rendering to other terminal emulators produce for these characters, > >especially the ones from GNOME, KDE, Apple, and mlterm? I cannot submit > >a patch to glibc based on the data of just 1 terminal emulator. As I commented in private to Bruno, Apple's Terminal.app even has broken cursor positioning behavior for CJK and nonspacing characters, so I think it's hopeless to try to use it for Indic scripts... Rich -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
