Hi, > Yes. It is also the future. > ISO-2022 may be nice, but it is not the future.
Please note that not all terms I proposed are related to ISO-2022. It is only a part of my proposal and not the most important one. I agree UTF-8 will be more important than ISO-2022 in future. However, I insist that locale (LC_CTYPE)-sensibility is more important than UTF-8 support, since UTF-8 should be used via UTF-8 locale (LC_CTYPE=foo_bar.UTF8). I want to explain other terms. Your proposal means at most 30 points for combining character. I think it is not fair to give such high points for combining character (vital for Thai people) while no points for doublewidth (vital for CJK) nor bidi (vital for Arab/Hebrew). Thus I included doublewidth and bidi terms. If you change your mind not to include combining character terms, please not to include doublewidth and bidi terms. wcwidth() is a UNIX standard and should be followed, though so far I don't know any terminal emulators do. I included wcwidth() term because I think it is important to promote standard. > Policy should serve as a guideline, not a sneaky coronation of some > particular terminal emulator as Debian's mandated default. I fully agree with this point. Did you think I am taking such a sneaky way? I gave 10 points for ISO-2022, just same as UTF-8. Since xterm already supports UTF-8, it is not likely that kterm becomes default. I mentioned a few particular terminal emulaters such as xterm, kterm, and jfbterm in my proposal only because I wanted to say that my proposal is not a vaporware and that ISO-2022 is an encoding in real use. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://surfchem0.riken.go.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
