Re: X input methods for utf-8?

[Ienup Sung <ienup.sung@xxxxxxxxxxx>]

Hi,

Thanks for your email first of all. I also agree with you that
Xlib can output UTF-8 directly without requireing to do additional iconv.

I also would like to point out that Solaris is also doing similar thing,
i.e., all CJK language engines and input systems are running in their
own codesets like eucCN, eucJP, Shift JIS and so on, and, we do also do
some code conversions between the X I18n lib and the language engines/input 
systems so that Xmb/wcLookupString will give you UTF-8/UTF-32 if your current
locale is a UTF-8/Unicode locale and Shift_JIS text if your current locale is
Japanese Shift JIS locale. I'm sure Hidetoshi Tajima and/or Hideki Hiura from
our group at Sun hopefully can provide us more info on this and also would
like to point out that all these X I18n sources merged with XF4.0.2 including
htt input method server that houses various language engines and input systems
and IIIM implementation are downloadable from www.li18nux.org and they are
under GPL in my understanding.

With regards,

Ienup


] Date: Tue, 30 Jan 2001 21:11:36 +0100 (CET)
] From: Bruno Haible <haible@xxxxxxx>
] Subject: Re: X input methods for utf-8?
] To: linux-utf8@xxxxxxxxxxxxxxxxxxxx
] MIME-version: 1.0
] Content-transfer-encoding: 7bit
] 
] 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/
-
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/lists/