Re: [I18n]xterm and XIM

[hiura@xxxxxxxxxxx]

> From: Tomohiro KUBOTA <tkubota@xxxxxxxxxxx>
> Why?  I wrote three codes, one of which will be compiled depending
> on the platform.  I think all three of them are not portable.

iconv() with codeset name aliasing, codeset name normalization (all
can be self contained, thus no external symbol importing is nesessary)
plus if nessesary an external iconv package would carry enough
portability as virtually same level as the other combinations for the
time being. Naming convention standards will increase the portability
from now on. Time goes by while we hang on there, we can improve X11's
UTF-8 support as standard aside, hopefull binary compatible way, we'll
get much better portability among platforms and subsequent versions on
the same platform.

> > 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.
> 
> It is a good effort.  It will improve the portability of iconv().
> ("we" means Li18nux?)

Not necessarily limit to Li18nux, all of us whom with good will to
resolve the problem. ;-)

> Then please stop to release buggy Unicode :-)  (This is just a joke.
> I never blame you about the bugs.)

Please accept my sincere apologees (;-;).
I (as a part of UTC) will continue work hard fixing and improving Unicode.

> I understand this point.  I wish iconv() were very portable from the
> beginning.  However, will the Li18nux's guideline on iconv() be
> popular and portable?  Not only Linux but also *BSD and commercial
> Unices will follow the guideline?  Even if the answer is "yes",
> when is it realized?
> nl_langinfo(CODESET) is an XPG5 function but in reality many systems
> lacks it.  How about iconv() guideline?

Not only Li18nux.org and its contributing members but everyone who
would be involved with implementation around iconv modules will have
to work hard to deploy. We all need such guideline for sure.

> However, without XLOCALE, we could not use locales on some systems
> including Linux till recently.

Let me rephrase what I've said earlier.
I am not saying X Consortium's I18N team should have not introduced
X_LOCALE. X_LOCALE was absolutely necessary as X's functionality at
that time, but not in the form we've introduced as a compilation time
switch which only results requiring separate binaries.
We could have done better than that. What I regret is we have
not introduced X_LOCALE as runtime configuration option while we could
have done so with a little extra effort. The portability I meant
includes virtical portability across the versions in addition to
horizontal portability across the platforms.

Let me give you one example of my early days with X_LOCALE.
I had several systems running SunOS4.x with and without locale
handling capablities installed at that time, and I had to have
two duplicate copies of X11R5 build, one with _Xsetlocale() and the 
other with system's setlocale().
Because of just such tiny _Xsetlocale() symbol reference, two sets
of binaries were needed, even though there was no technical necessity
of requiring so, as other I18N capabilities in Xlib were designed to
be configurable runtime.

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