Re: [desktop] why kde and gnome's menu situation sucks
Hi,
At Wed, 23 Oct 2002 18:29:17 -0500,
Steve Langasek wrote:
> I've recently picked up the multibyte support I had started adding to
> Eterm a year ago, and making good progress. When I'm done, Eterm will
> support UTF-8, as well as other East Asian encodings. It should also
> support Thai encodings, since AIUI the main issue with Thai is combining
> characters, which I'm testing plentifully.
Fantastic!
> I've been reviewing your posts regarding LC_CTYPE sensibility, and
> honestly, I don't understand what all the concern is about -- or how so
> many xterms can handle this so badly. From what I see, good LC_CTYPE
> handling seems to follow naturally from proper application of
> XmbDrawString(), mbtowc(), and wcwidth()[1] -- or are there bugs in
> these functions?
You are right, good usage of XmbDrawString(), mbtowc(), and wcwidth()
is enough for most of softwares. However, most developers don't know
even the existence of these functions -- most developers seem to
easily forget the fact that there are various languages and countries
in the world.
Note that XmbDrawString() cannot be used for terminal emulators,
because the idea of "font set" (XFontSet structure) is only a
collection of fonts from various needed charsets. It doesn't
take care of relationship between these fonts. (For example,
jisx0208 font must be as twice as wide than iso8859-1 font in
EUC-JP terminal). Thus, even i18n-ed terminal emulators like
xterm, rxvt, eterm, and mlterm don't use XmbDrawString(). Also,
terminal emulators must take care of current cursor position
in "column", which also makes usage of XmbDrawString() impossible.
Instead, terminal emulators use conventional XDrawString().
Thus, they must manage doublewidth characters, combining characters,
bidi, and so on by themselves. Also, because of this, terminal
emulators must emulate locale behavior.
Also, for east Asian, XIM support is needed to input thousands of
characters (this is not limited to terminal emulators).
Does eterm use XmbDrawString() ?
> > There are several such examples that newer version of some software
> > drops i18n support because of careless development. It is very sad
> > for developers who wrote i18n support for previous version. This
> > *does* sometimes occur because most developers in the world don't
> > know about i18n well nor can test in various (especially, non-European)
> > locales.
>
> Testing the *display* of other charsets should be easy enough; just
> download Markus Kuhn's reference UTF8 text file, and play around with
> that + iconv...
Right.
---
Tomohiro KUBOTA <kubota@debian.org>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
Reply to: