Date: Thu, 11 Jun 1998 16:44:15 +0900 From: Jun-ichiro itojun Itoh <itojun@iijlab.net> To: Konstantin Chuguev <joy@urc.ac.ru> Cc: Gary Kline <kline@tao.thought.org>, Terry Lambert <tlambert@primenet.com>, hackers@FreeBSD.ORG Subject: Re: internationalization Message-ID: <11417.897551055@coconut.itojun.org> In-Reply-To: joy's message of Thu, 11 Jun 1998 12:14:40 %2B0600. <357F75D0.CEBAC766@urc.ac.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
>> Yes, iso-2022 families are quite important for supporting
>> asian languages. Unicode is, for us Japanese, quite incomplete and
>> unexpandable.
>Do you mean Unicode does not cover all the CJK characters?
Unicode maps different Chinese/Japanese/Korean letters into the same
codepoint. The actual appearance (gryph) will be determined by
the selection of font. (so, there will be font just for Chinese,
font just for Japanese, and font just for Korean).
Therefore, it may be sufficient for supporting single asian language
(for example Japanization), it is not sufficient for
multilingualization (C/J/K support at the same time). With Unicode,
you will never be able to write a plaintext with C/J/K letters mixed.
For example, I frequently write such a plaintext, for list of plates
for chinese restaurant, with description in Japanese attached.
Such a plaintext cannot be generated with Unicode.
>What is "unexpandable"?
Unicode people stressed Unicode because of the "fixed bitwidth"
nature of Unicode. Therefore, basically they will not be able to
support more than 2^16 letters.
Recently Unicode introduced "surrogate pair" which makes Unicode
a variable bitwidth character set. This breaks the key feature of
Unicode, and it shows that Unicode is not expandable as nature.
(Correct me if I'm wrong about "surrogate pair"...)
iso-2022 is well designed to accomodate new character sets to appear
later. Even with the most simplest subset it can accomodate bunch of
character sets.
Handling bare iso-2022 string is some hard to implement because it
is variable length (yes I agree). If we can provide a good library
for iso-2022, then there's no reason for us to migrate to Unicode.
>> Yes, for Japanese, Chinese and Korean iso-2022 based model (euc-xx
>> falls into the category) is really important. However, I
>Why not to support both ISO 2022 and Unicode? Yes, it is more difficult
>to implement. But otherwise we can lose compatibility with other systems.
Of course my library support both of them. If you say
setrunelocale("UTF2"), the internal and external representation
will be come Unicode. If you say setrunelocale("ja_JP.iso-2022-jp")
it will be come Japanese iso-2022-jp encoding.
I'll try to release my library with sample application sooner.
I think I can give you the tarball at New Olreans :-)
itojun
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?11417.897551055>