Hi, I think this proposal is too biased to UTF-8. UTF-8 is mere one encoding out of many encodings in the world, though it is an important one.
Thus, I propose to add + <item>If the terminal emulator supports ISO-2022 encoding, + add 10 points. + <item>If the terminal emulator changes its encoding + according to LC_CTYPE locale, add 10 points. + <item>If the terminal emulator supports doublewidth + characters, add 10 points. + <item>If the terminal emulator supports bidi, add 10 points. + <item>If the terminal emulator obeys wcwidth(), add 10 points. ISO-2022 is another international (multilingual) encoding. Now kterm and jfbterm supports it. It has longer history and wider code space than Unicode. Some softwares such as emacs, lv, and so on may want to run on ISO-2022 terminal. Though there are no terminal emulators which obey LC_CTYPE locale now, xterm will support this in near future. It means not only using proper font (in KOI8-R locale, use KOI8-R font) but also multibyte processing (in UTF-8 locale, EUC-JP locale, and so on). Doublewidth support is important for CJK (east Asian) people. Bidi support is important for Arab/Hebrew people. Xterm supports doublewidth in UTF-8 mode. It will support bidi soon. wcwidth() is an XPG5 function which returns width of characters. Glibc-2.2 supports it. Since softwares which run on terminal emulators may rely on wcwidth(), it is important that terminal emulators obey it. Xterm will meet this condition soon. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://surfchem0.riken.go.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
