2009/6/15 Corinna Vinschen: >> > Define the default for ja, ko, and zh to use width = 2, with a >> > @cjknarrow (or whatever) modifier to use width = 1. >> >> I think it is good idea. > > If everybody agrees to this suggestion, here's the patch. Tested > with various combinations like > > lang=ja_jp.ut...@cjknarrow > lang=ja...@cjknarrow > lang=ja.ut...@cjknarrow > lang...@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.ut...@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
