[openi18n-im:01277] Re: moving from csconv to iconv?
Motonobu Ichimura <[email protected]> Wed, 9 Mar 2005 17:41:18 +0900
| Newsgroups | gmane.comp.internationalization.input-methods |
|---|---|
| Organization | Momonga Project |
| Message-ID | <[email protected]> |
On Wed, 09 Mar 2005 02:36:16 -0800 Hidetoshi Tajima <[email protected]> wrote: > AShiZaWa KaZuNoRi wrote: > > >>I believe this has been discussed before, but I can't find > >>a thread on it right now. Maybe someone can point me to one? :) > >> > >>I would like propose that we move from using csconv > >>to iconv for im-sdk. With the prevalence of iconv > >>in FOSS and the availability of GNU libiconv > >>for non-glibc platforms this seems very natural > >>and im-sdk will also be able to lose quite a bit of weight. > >> > >>Are there any known issues with using iconv instead of csconv? > >> > >> > > > >I thought that no module use csconv on any platform for now, or > >am I wrong? > > > > > Seems recent change made in lib/iiimcf has started using it again. I'm > not sure if this > is really needed, though. libiiimcf may use it for conversion from/to UTF-16 to/from UTF-8. If we want to remove it, we can do. In this case, it seems better to extend libEIMIL to handle these conversions.(Because libEIMIL has some functions to convert unicode-related encodings) When we move to iconv, the most important thing is that LE SPI doesn't specify how to convert native chars to UTF-16. As the result of lacking it, many LEs uses csconv for conversion and we cannot move to iconv, I think. so I would like propose 1) Extend libiml API's to and capsulize conversion library in these API. 2) Modify each LE to use 1). We should take commercial/external LE packages into consideration. 3) LE SPI speficication tells LE developers to use 1). 1) breaks API, and may break ABI. so I'd like to suggest these changes will be done after r12_2 release. Regards, famao