X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org MIME-Version: 1.0 In-Reply-To: <20090512173153.GY21324@calimero.vinschen.de> References: <20090512165404 DOT GW21324 AT calimero DOT vinschen DOT de> <416096c60905120956n5521929bm69586f5e6325a994 AT mail DOT gmail DOT com> <20090512173153 DOT GY21324 AT calimero DOT vinschen DOT de> Date: Fri, 15 May 2009 00:58:38 +0900 Message-ID: <3f0ad08d0905140858j17c7b374paa649f18ef18178d@mail.gmail.com> Subject: Re: [Fwd: [1.7] wcwidth failing configure tests] From: IWAMURO Motonori To: newlib AT sourceware DOT org, cygwin AT cygwin DOT com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 2009/5/13 Corinna Vinschen : >> http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c > > This looks nice. Do you import Markus Kuhn's wcwidth implementation? >> Trouble is, there's the thorny issue of the "CJK Ambiguous Width" >> category of characters, which consists of things like Greek and >> Cyrillic letters as well as line drawing symbols. Those have a width >> of 1 in Western use, yet with CJK fonts they have a width of 2. That's >> why Markus Kuhn's code includes the mk_wcswidth_cjk() variant. > > We should use the standard variation alone, imho. I don't think so. 1) It is very very inconvenient for me :-) (Now, I apply the local patch of CJK width support to cygwin1.dll in my environment.) 2) Unicode Standard Annex #11 http://www.unicode.org/unicode/reports/tr11/ recommends: > 5 Recommendations (snip) > When processing or displaying data (snip) > Ambiguous characters behave like wide or narrow characters depending > on the context (language tag, script identification, associated > font, source of data, or explicit markup; all can provide the > context). If the context cannot be established reliably, they should > be treated as narrow characters by default. The recommendation is independent of legacy encoding. I think that a new locale category that specifies the "context" is necessary. Because the "context" influences only the display or text layout. However, there is no such standard now. Therefore, I propose to use *_cjk() when the language part of LC_CTYPE is 'ja', 'ko', 'vi' or 'zh'. -- IWAMURO Motnori -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/