Ienup Sung writes:
> What I meant by 'The "much better" in that context...' is that if you
> have a properly internationalized application (that is, by using X I18n
> functions calls like Xmb/wcDrawString, Xmb/wcLookupString and so on)
> then your application will work on any kind of locales/codesets including
> UTF-8.
Hi,
This is nice theory. But the problem Bram is facing is:
- He would like to have vim run in an UTF-8 locale with a Japanese
input method.
- Most input methods for Japanese assume an EUC-JP encoding.
- The XIM functions in Xlib pass the text directly to the callbacks
the application has registered, without conversion. Look at imCallbk.c.
Thus some conversion from EUC-JP to UTF-8 must be done somewhere. Bram
currently must do it in iconv. But I think doing it in Xlib would be
better, because there are many applications like vim, and some of them
don't want to use iconv - they just want to get UTF-8 input.
> And, at the sametime, as I also pointed out in several occasions, I also see
> and certainly believe that there are cases that a single application would
> want to input and output more than one codeset text data preferably one of
> them in UTF-8/UTF-32 and in that case, such application would require to
> have some level of code conversions in it hopefully through iconv(3C) as
> the current APIs are not really covering all such needs and also not so
> convenient to do such programming.
Agreed.
Bruno
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/lists/
