> > I dont think that IIIMF is really going to address the console > > issue at that level. > > Well, it is certainly supposed to. Do you mean that developers will > not make use of it? If the people responsible for putty, Cygwin, ssh, > gnome-terminal and the console don't put in IIIMF capability, you or > someone else with similar needs almost certainly will. I haven't > examined the IIIMF testing standards proposed by Free Standards Group > for next month, but my understanding is that conforming distributions > will eventually be required to ship with at least a minimum list of > conforming utilities and apps. If you want one, tell Li18nux and FSG > yourself.
I was imagining a use of libiiimf or something like it that doesnt need support in cygwin or putty. Imagine having the input layer be integrated in between putty and say bash or vi (like the terminal line-editing is). Putting the support in in one place could solve nearly all the text-mode input situations. >The internal coding used by any software is totally irrelevant to any >other software, or to users. UTF-16 stores BMP CJK characters in two >bytes each, whereas UTF-8 requires three. This saves some space in a >number of tables. It isn't a big deal, but it is a very reasonable >design choice. If the unicode standard is extended beyond 0x10FFFF, it can become a problem, especially in protocols. (utf-16 is unsuitable for protocols imo). Also the bytes saved in the tables for the lower han indicies will be spent back when supporting extension, compatibility, and supplemental han characters (using surrogate pairs). -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
