> Thus, IMO, we should stop the discussion on whether Han Unification
> is good or bad and we should discuss about how CJK glyph distinction
> is acheved based on Han character unification. (How can proper font
> be choosed? How can the font choosing mechanism avoid to be a
> vaporware?)
My impression is that this subject is not urgent for this round.
Currently our problem is not having enough unifonts, no matter with which
cjk national bias.
On the other hand, CJKTeX and Omega give us the means to nicely print
all the rarest combination of multilingual textbooks that we might like
to have.
As Bruno said, some solutions for displaying such rare multilingual books
will even be available, because they are a part of Unicode 3.1.
There are really not many areas in linux-utf8 where matters are so clear
and well ordered as they are on this question that you are raising.
> > This was possible thanks to the hardwiring of TCL strings to Unicode!
>
> For many years, TCL/TK supports Unicode as internal encoding but
> it does not support XIM input. This is why we use Japanized local
> version of TCL7.4/TK4.2 (or quick hack of TCL8.0/TK8.0) even now.
> We sometimes observe that some software is advertised to support
> Unicode but it actually fails to work conveniently with Japanese.
Which is due to other difficulties that currently exist with using
the ja_JP.utf-8 locale. A general lack of support, including in XIM
and XIM applications.
> (I thought you use TCL/TK and other Unicode software with Han Ideogram.
> Now it is revealed that you don't use Han Ideogram and it is natural
> you don't know about such daily inconveniences.)
Maybe some of the Unicoders underestimate these difficulties. They may
not always fully understand why Redhat and SuSE still use euc-jp as the
default encoding for Japanese and are not more courageous in moving ahead
to utf-8. There are many urgent problems, but the variant selection
problem is not one of them, and it seems to have been solved anyway.
> > The Unicode language tags are a bad compromise intended mostly
> > to help stubborn Japanese ISO 2022 fans
>
> The fact we need multiple glyphs for one Han character has no
> relation to ISO 2022.
The fact that people want this to be handled at the coding system level
and not at the text formatting level does have to do with ISO-2022.
Having it built into the coding system is certainly useful for ensuring
round-trip conversion compatibility between utf-8 and iso-2022. But I
don't see for what else it could be necessary enough to justify the
bloating of the coding system that it causes.
Unfortunately the relation to iso-2022 is even more complicated, with a
lot of interference from political sentiments.
> I don't stick to language tag if our need is satisfied that proper
> font can be selected according to language of text. However, we
> need some standard to do so before Unicode will become popular in
> CJK world. Do you have any idea for alternative?
Unicode is already becoming popular in the CJK world. Microsoft and others
are setting the pace faster than we can cope. And font selection can
easily be done at the hypertext level -- HTML, LaTeX, Rich Text and of
course also by using the Unicode 3.1 language tag.
> (We will need some more labors such as fixing conversion tables
> between Unicode and local encodings, concept of width, and so on
> before we can use Unicode as one of popular encodings. Otherwise,
> we cannot even start to use Unicode.)
There are still some urgent problems left to solve before LANG=ja_JP.utf-8
or LANG=fr_FR.utf-8 can become an acceptable default for the normal user.
The language tag problem is not one of them, but it seems to have been
largely solved already anyway.
-phm
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/lists/
