[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [I18n]xterm and XIM
Hi,
At Fri, 08 Jun 2001 07:24:04 -0700 (PDT),
hiura@xxxxxxxxxxx wrote:
> 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.
Why? I wrote three codes, one of which will be compiled depending
on the platform. I think all three of them are not portable.
Assume that Xutf8LookupString() works for platform A, B, and C,
__STDC_ISO_10646__ works for platform A, D, and E, and iconv()
works for platform B, C, and F. Then, having three codes will
work for platform A, B, C, D, E, and F, i.e., maximize the portability.
> 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?)
> 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.
Then please stop to release buggy Unicode :-) (This is just a joke.
I never blame you about the bugs.)
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?
> 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.
However, without XLOCALE, we could not use locales on some systems
including Linux till recently.
---
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/