Mail Archives: cygwin/2009/06/27/05:49:10
2009/6/15 Corinna Vinschen:
>> > Define the default for ja, ko, and zh to use width =3D 2, with a
>> > @cjknarrow (or whatever) modifier to use width =3D 1.
>>
>> I think it is good idea.
>
> If everybody agrees to this suggestion, here's the patch. =C2=A0Tested
> with various combinations like
>
> =C2=A0LANG=3Dja_JP DOT UTF-8 AT cjknarrow
> =C2=A0LANG=3Dja_JP AT cjknarrow
> =C2=A0LANG=3Dja DOT UTF-8 AT cjknarrow
> =C2=A0LANG=3Dja AT cjknarrow
Apologies for harping on about this, especially as it was me who
suggested the @narrow scheme in the first place, but I do think this
is the wrong way to go.
MinTTY currenly ignores POSIX locales completely, so I've been
pondering how to deal with locales and codepages more properly. One
thing I'd like to do is to automatically set LANG depending on the
Windows locale and the codepage and font settings in MinTTY (if LANG
isn't set already, that is).
Trouble is, what do I do if a cjkwide font is selected, yet the
Windows locale is not East Asian? I can't just randomly stick the user
into one of the three CJK countries, because people don't always take
kindly to being put into the wrong country.
That could be addressed by adding the @cjkwide modifier for non-CJK
languages, as discussed previously, but then MinTTY would still need
to parse the language setting to decide which modifier (if any) needs
to be used. Having the @cjkwide modifier only, independent of the
selected language, would keep things much easier to use and explain.
And then there's the Linux compatibility angle, where ja_JP.UTF-8
means ambiguous width 1 not 2.
To try to help with changing this, here's some text for the user guide.
Replace this:
"Right now the language and territory, as well as the modifier, are
not important to Cygwin, except to fix a single problem. There's a
class of characters in the Unicode character set, called the "CJK
Ambiguous Width Character set". For these characters the width
returned by the wcwidth/wcswidth function is usually 1. This is often
a problem in East-Asian languages, which historically use character
sets in which these characters have a width of 2. Kind of explains why
they are called "ambiguous"...
The problem has been fixed for now like this. wcwidth/wcswidth usually
return 1 as the width of these characters. However, if the language is
specifed as "ja" (Japanese), "ko" (Korean), or "zh" (Chinese), wcwidth
returns 2 for these characters. Unfortunately this isn't correct in
all circumstances, so the user can specify the modifier "@cjknarrow",
which modifies the behaviour of wcwidth/wcswidth to return 1 for the
ambiguous width characters to return 1 even in those languages."
With this:
"Right now the language and territory are not important to Cygwin, but
the modifier is used to deal with the issue of "CJK Ambiguous Width"
characters. For these characters the width returned by the wcwidth
function is usually 1. This is often a problem in East Asian
languages, which historically use character sets in which these
characters have a width of 2. Kind of explains why they are called
"ambiguous"... . (See http://unicode.org/reports/tr11/ for a full
explanation.)
Therefore, if the modifier "@cjkwide" is specified, wcwidth returns 2
for these characters. For example, with jp_JP.UTF-8 their width is 1,
whereas with jp_JP DOT UTF-8 AT cjkwide it is 2."
Andy
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -