enchant use hspell as is (iso-8859-8) and just convert the strings when using the hspell lib: http://www.abisource.com/viewvc/enchant/trunk/src/hspell/hspell_provider.c?view=markup
imho because hspell only use hebrew, it can internally continue to use hebrew only charset without nikud iso-8859-8 (or with nikud win-1255). it will be helpful if hspell will give the user convenience functions. this functions will that take utf-8 and return utf-8. the functions will convert the utf-8 to the hebrew only coding that hspell will use internally. p.s. i will be happy if hspell will give easy to use functions for using the library lingual info. in current version of hspell using lingual info is very hard. see: http://code.google.com/p/hspell-gir/source/browse/src/hspell-gir.vala 2012/3/12 Elazar Leibovich <elaz...@gmail.com> > On Mon, Mar 12, 2012 at 7:37 PM, Nadav Har'El <n...@math.technion.ac.il>wrote: > >> On Mon, Mar 12, 2012, Elazar Leibovich wrote about "Re: Unicode in C": >> > The simplest option is, to accept StringPiece-like structure (pointer to >> > buffer + size), and encoding, then to convert the data internally to >> your >> > encoding (say, ISO-8859-8, replacing illegal characters with >> whitespace), >> > and convert the other output back. >> >> This is an option, but certainly not the simplest :-) >> > > It was the simplest idea *I could think of* at this moment ;p > > >> >> What "iconv-like library"? >> > > iconv-like means, "Do you mind using iconv from glibc, and if that's a > problem due to support in Windows, embedded systems, etc that do not > feature glibc, do you mind having a dependency on other library, such as > ICU, or at least something more lightweight like that would handle all > UTF-* conversions?" > > >> >> I'm not ruling this idea out. But what worries me is that at the end, >> my users only use 1% of this library's features - e.g., I'll never need >> this library's support from converting one encoding of Chinese to >> another. So people who want to use the 50 KB libhspell will suddenly need >> the 15 MB libicu. >> > > At least when using iconv on linux this is not the case. First, this > library is available at every distro, and second, iconv is smart enough to > split the functionality amongst many .so files, and to dynamically load > only the required shared objects at runtime. I'm not sure what's the state > of iconv at Windows though. Maybe you can fallback there to native system > calls. > > That said, on a second thought, all the single-byte encoding seems to me > more and more deprecated. Thus, I think it might be sufficient to support > only UTF-16 and UTF-8. UTF-8 is common at network and files, and UTF-16 is > common as inside format in C++ libraries Java and C#, so it's important to > support it for easier interoperability with those. > > _______________________________________________ > Linux-il mailing list > Linux-il@cs.huji.ac.il > http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il > >
_______________________________________________ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
