On 6 May 2002, Juliusz Chroboczek wrote:
> JS> I had to make up ko_KR.UTF-8 different from en_US.UTF-8 to make my
> JS> transition to ko_KR.UTF-8 work as I intended.
>
> Fair point.
>
> Of course, the long-term solution is to use font technologies that do
> language-dependent and contextual font and glyph substitution.
I agree. However, it's not only fonts but also CompoundText that led
me to modify en_US.UTF-8 to get ko_KR.UTF-8. Actually, by specifying
'-ko-' in additional style field of XLFD, I found it better to leave
iso10646-1 entry at the top in XLC_LOCALE. Here's a quote from my message
<quote>
Subject: [I18n]Re: en_US.utf8/XLC_LOCALE bogus?
Date: Mon, 29 Apr 2002 17:15:59 -0400 (EDT)
U+4E00 (CJK ideograph number one) is in all CJK character sets.
If jisx0208.1983-0 is listed
*before* ksc5601.1987-0 in XLC_LOCALE for ko_KR.UTF-8,
an application running under ko_KR.UTF-8 cannot send
the character to an application running under ko_KR.eucKR
locale because U+4E00 would be encoded as
ESC $ B 30 6C ( 0x30 0x6C : U+4E00 in JIS X 0208 GL)
instead of
ESC $ ( C 6C 69 ( 0x6C 0x69 : U+4E00 in KS C 5601 GL)
Of course, this would not be an issue if UTF8_STRING is used.
</quote>
Jungshik Shin
_______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
