On Wed, 2 Dec 1998, Glen wrote:
> Would any Linux expert be willing to post a status report on Linux's support
> for Unicode?
Quite many people talked about GUI aspect of Unicode support and
mentioned Qt/KDE, GNOME, Perl, Tcl/Tk, etc. However, no one mentioned
about Unicode support in C so here it goes.
Next release of GNU libc which Linux will use sooner or later has a
rather complete support of locale-related
APIs(iconv,localedef,setlocale, etc) defined in Single Unix Spec 98. On
the surface, that doesn't sound much like related with Unicode support,
but it is. It'll support UTF-8 as ONE of many multibyte encodings
supported(using UCS-4 as wide char) and it won't be much hard to build
up locale databases for various languages and territories based on
UTF-8(e.g. en_US.utf8, fr_CA.utf8, ko_KR.utf8, zh_CN.utf8, ja_JP.utf8,
> In particular, I'm curious about the contenders for "standard GUI" on Linux:
> GNOME, KDE, and whatever else there might be. I admit that I still know very
> little about them, but it appears to me as though GNOME and KDE are trying
> to "help the Linux community answer the challenge of Windows' consistent
> GUI" by introducing GUIs based on single-byte char and string APIs. Then, if
> you want Chinese, you can simply install a derivative version of GNOME or
> KDE, hacked to support Chinese. If you want Japanese, you install a
> different hacked version. Then, you'll need to run hacked versions of any
> app you want to run on your "non-standard" GUI. And this is supposed to
> answer the consistency challenge?
Actually, GNOME can support CJK multibyte encodings *without* patch
in principle and UTF-8 support may be also possible as it can be just
regarded as another multibyte encoding. Japanese has no problem getting
GNONE applications to work with Japanse input method for X11 while
Korean has some trouble with a few Korean input method for X11. It's
been under investigation. In case of Chinese, a trouble is there's no
freely available X11 input method server.
As for Qt/KDE, until recent change in Qt licence, it was impossible to
distribute patches to support CJK multibyte encodings to Qt/KDE (A funny
thing was KDE web page advertised Chinese locale support while the
official release of Qt doesn't support multibyte encodings at all
although there was an unofficial patch, which might have infringed upon
Qt license terms). Now with the 'opening-up' of Qt, Troll tech people
reportedly contacted those with patches for Japanese and Korean support
for possible inclusion of them in the future release. All of these
may not be much relevant as Qt will have "clean"(?) UCS-2 support
(I wish that would be UTF-16 as others do).
> I understand the problem of dragging legacy balls-and-chains, but I would
> think that any *new* "alternative to Windows" would start out with a pure
> Unicode-based GUI API. Get the API right, then let the open source community
> fill in the nasty implementation details in the widgets (bidi support,
> composition, etc.) Instead, it appears as though the Linux community is
> attempting to create new soon-to-be-legacy single-byte GUIs (with multiple
> double-byte hacked derivatives) as their answer to Windows's growing
> worldwide consistency.
One of problems with Linux I18N might be communication between
mainstream developers(more or less fluent in English) and those in
Japan,Korea and China. Japanese (and to lesser extent Chinese and
Koreans) have done a lot of things on I18N and L10N, but it seems that
what they have been doing is, more often than not, left unknown outside
their own countries. (there are lots of useful web pages in Japanse
about I18N and L10N of Linux and FreeBSD.......).
> What am I missing? I've asked gnome.org, kde.org, redhat.com, and several
> others. Not a single response. Would someone knowledgeable in the ways of
> Linux be willing to fill me in?
Did you ask debian.org? As far as I18N/L10N is concerned, Debian is
arguably the best among Linux distributions.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:43 EDT