Bug#83063: PROPOSED] enhanced x-terminal-emulator policy
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 <kubota@debian.org>
http://surfchem0.riken.go.jp/~kubota/
"Introduction to I18N"
http://www.debian.org/doc/manuals/intro-i18n/
Reply to: