Re: [I18n]xterm and XIM

[hiura@xxxxxxxxxxx]

> From: Tomohiro KUBOTA <tkubota@xxxxxxxxxxx>
> 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.

Self contradicting.
If suppose your forth argument is optimal and we should just accept
platform dependence, your first argument no longer convinsing,
sine you can write apps in portable portable way withing the single
platform(what a self contradicting ;-P) accepting multiple binaries
having bunch of #ifdef's.

About iconv codeset names variants;
Of cource we are all aware of the problem. Therefore we have been
trying to come up with the solutions, such as codeset name aliasing,
codeset name normalization, developing standard naming convention
guideline, etc, in X, glibc, and standards.

Ignoring those and just focusing on to release a reasonably usable
software just as fast as we can regarless, is sometime really damaging
the proper solutions.

> > 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?

Not at all. As I explained apecifically with example, I meant

| Running XIM server in ja_JP.eucJP locale and connecting to it from the
| X client running in ja_JP.UTF-8 locale or in ja_JP.sjis locale is
| perfectly normal usage of XIM, and supported by XIM protocol design.
| 
| What I was talking about is only for UTF-8 xterm, not for XIM server.

XIM Server runs in the locale the user sets on longin time.
UTF-8 xterm runs in <user's specified lang_teritory>.UTF-8 locale.
In any case, the UTF-8 xterm ingores what user set as .CODESET and
operate in as if it is in .UTF-8 locale, the argument like "no
software should take the license to override the user's locale choices"
equalls to denying what UTF-8 xterm itself does, so it is also self
contradicting.

> 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. 

Run ami in ko_KR.EUC-KR and connect to ami from the X clients running
ko_KR.UTF-8 locale. It sould work otherwise ami has bugs.

> 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.

I agree in principal, but as I have been being a party of developing
Unicode Standard and ISO/IEC 10646 for long time and has been using
UTF-8 locales only since '93, I am strong advocate of UTF-8 locale, 
so I want UTF-8 locale to be always there in all systems. ;-P
And it is much better to require UTF-8 locale to be installed on the
system than to require non standard APIs or multiple binaries to be
present in the system.

About multiple binaries; Why I strongly object? That is from my regret
that I overlooked XLOCALE to create separate binaries rather than
runtime binding while it can easily be done while I was working on
X Consortium's X11R5 I18N project back on '89. It created a lot of
problems for long years until the systems require XLOCALE got
obsoleted. 

--
hiura@{sun.com,li18nux.org,kondara.org,unicode.org} http://www.li18nux.org
Chair, Li18nux/Linux Internationalization Initiative, Free Standards Group
Architect/Sr. Staff Engineer, Sun Microsystems, Inc, USA  FAX 650-786-9553


-
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/linux-utf8/