Hi,
At first I am sorry I am too busy to catch up with recent important
discussions about XTerm and ISO2022. I will accept any implementations
which will enable...
wget ftp://foobar/xterm-<version>.tar.gz
tar xzf xterm-<version>.tar.gz
cd xterm-<version>
./configure --enable-wide-chars
make
LC_CTYPE=ru_RU.KOI8-R ./xterm & # using KOI8-R
LC_CTYPE=ja_JP.eucJP ./xterm & # using EUC-JP
LC_CTYPE=zh_TW.Big5 ./xterm & # using Big5
(and so on)
kinput2 &
LC_CTYPE=ja_JP.eucJP XMODIFIERS=@im=kinput2 ./xterm & # using XIM
(and so on)
./xterm -u8 & # using UTF-8 in any locales
At Thu, 31 May 2001 01:02:32 +0200 (CEST),
Bruno Haible <[EMAIL PROTECTED]> wrote:
> The Unicode 3.1 language tag characters are described in Unicode UAX
> #27. It's obvious that iconv converters from UTF-8 to all non-ISO-2022
> encodings shall silently ignore and throw away these characters. The
> real question is what to do with the ISO-2022-JP-2 encoding.
>
> My plan is to change the glibc ISO-2022-JP-2 encoder in such a way
> that inside a "LANGUAGE j a" tagging, it tries to convert first to
> JISX0208, JISX0212 before trying the Chinese and Korean encodings, and
> similarly give a preference to Chinese characters sets inside
> "LANGUAGE z h" and to the Korean character set inside "LANGUAGE k o".
>
> Does this meet the requirements of glyph shape sensitive Japanese
> users? What do you think, Tomohiro?
Yes, it would be helpful in future, I think, though, so far, I don't
know language tags will be widely used in future or not.
BTW, I heard that MAPPINGS/EASTASIA data in Unicode ftp site will
be moved into OBSOLETE directory. It seems politically difficult
for JIS X 0802-including encodings (such as EUC-JP, Shift_JIS,
Microsoft's CP932, IBM's one, Apple's one, ...) to share a common
JIS X 0208 <-> Unicode conversion table.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
