Re: [I18n]xterm and XIM

[Tomohiro KUBOTA <tkubota@xxxxxxxxxxx>]

Hi,

At Thu, 07 Jun 2001 18:36:24 -0700 (PDT),
hiura@xxxxxxxxxxx wrote:

> Relying on the __STDC_ISO_10646__ is even worse than Xutf8LookupString
> because of its compilation binding. It is not wise to create separate
> binaries just for wc encodings which has been an opaque and being
> bound runtime for long POSIX/C history, so we should avoid relying on
> __STDC_ISO_10646__. 
> Although I am in favor of introducing Unicode support in Xlib for the
> application use, but not in the form of introducing functions.
> Introducing new functions just for different encodings is not a wise
> way to address the problem because it also results separate binaries
> to resolve symbols with linkage editor. Instead, mb/wc encodings
> should be something settable/gettable via existing set/get operations.
> 
> Why don't we just use iconv for the time being until such Unicode
> support API is official?

Since nl_langinfo(CODESET) and iconv() is not very portable.
(Even when these functions are available, name of encodings
may be different.  We need a concrete encoding name for UTF-8.
And more, the return value of iconv_open() must understand the
return value of nl_langinfo(CODESET), which is not guaranteed.)

Of course Xutf8LookupString() and __STDC_ISO_10646__ are not
portable, too.  There are no perfect way.  This is why I proposed
as much as three different codes to do one thing.  Adding one
different way increase portability a little.

However, the biggest reason is that people who mainly develop
and maintain UTF-8 XTerm like Xutf8* and __STDC_ISO_10646__ than
iconv().  My interest is to release a reasonably usable software
as fast as we can.  iconv() is OK.  Xutf8LookupString() is also OK
(if the bug(?) is fixed).  Since my interest is free systems such
as Linux and *BSD, __STDC_ISO_10646__ is not very good (but not
harmful if alternative way is provided).  If I had enough time
to maintain XTerm, I might develop usable i18n terminal emulator
(nobody has achieved this goal so far).

I think "compilation binding" or "separate binary" is not bad at all.
In any case, Linux, FreeBSD, NetBSD, and so on cannot share a common
binary.  In this case, "separate binary" does not mean multiple
binaries in one system.  ("Separate binary" is bad only when it
is needed in one system to satisfy multiple needs, for example,
"grep" for 8bit languages and "jgrep" for Japanese.)


> Not accurate.
> Some XIM servers may only run on the specific locales, but such
> restrictions do not affect to the X clients because they are
> communicating over the wire via XIM protocol.

You mean, popular XIM servers such as kinput2 and xcin work well
under UTF-8 locales?  I tested ami (Korean XIM server) in ko_KR.UTF-8
locale but it claimed that it failed to get a fontset and didn't work.

If I was wrong, it is a good news.  (I might configured XIM servers
wrongly...)

Anyway, I think the design is not very good that XTerm calls
setlocale(LC_CTYPE,some_UTF-8_locale).  Users may have no UTF-8
locales.  Users should be able to use UTF-8 XTerm without being
aware of the fact XTerm use UTF-8 as the internal encoding.
If XTerm requires UTF-8 locales, this requirement will fail to
be achieved.

---
Tomohiro KUBOTA <kubota@xxxxxxxxxx>
http://www.debian.or.jp/~kubota/
"Introduction to I18N"  http://www.debian.org/doc/manuals/intro-i18n/
-
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/linux-utf8/