From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 402 invoked by alias); 3 Nov 2009 21:00:31 -0000 Received: (qmail 389 invoked by uid 22791); 3 Nov 2009 21:00:29 -0000 X-SWARE-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SARE_SUB_ENC_UTF8 X-Spam-Check-By: sourceware.org Received: from smtpout.karoo.kcom.com (HELO smtpout.karoo.kcom.com) (212.50.160.34) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 Nov 2009 21:00:25 +0000 Received: from 213-152-38-55.dsl.eclipse.net.uk (HELO [192.168.0.8]) ([213.152.38.55]) by smtpout.karoo.kcom.com with ESMTP; 03 Nov 2009 21:00:23 +0000 Message-ID: <4AF099EA.4040202@dronecode.org.uk> Date: Tue, 03 Nov 2009 21:00:00 -0000 From: Jon TURNEY User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: cygwin-xfree@cygwin.com Subject: Re: X11R7.5 and C.UTF-8 References: <4AE8539E.9080004@cornell.edu> <4AE8D942.8020806@dronecode.org.uk> <416096c60910281707t3249dfb7tc6d0caf0e57ba626@mail.gmail.com> <4AE99BAD.6060303@dronecode.org.uk> <4AE9A8AD.2030702@cornell.edu> <4AE9AE57.8010405@dronecode.org.uk> <4AE9E8DE.9010803@dronecode.org.uk> <416096c60910291320r4fb374ebhe5c7167dfe6fdce0@mail.gmail.com> In-Reply-To: <416096c60910291320r4fb374ebhe5c7167dfe6fdce0@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-xfree-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-xfree-owner@cygwin.com Reply-To: cygwin-xfree@cygwin.com Mail-Followup-To: cygwin-xfree@cygwin.com X-SW-Source: 2009-11/txt/msg00033.txt.bz2 On 29/10/2009 20:20, Andy Koppe wrote: > 2009/10/29 Jon TURNEY: >> I've put a patch in bugzilla [1] which can be applied to >> /usr/share/X11/locale to temporarily repair this problem. >> >> This needs to be looked at more deeply, though, as I'm not sure I've fully >> understood what that locale data is being used for, or specified C.UTF-8 >> correctly. >> >> [1] http://sourceware.org/bugzilla/show_bug.cgi?id=10870 > > I think the patch makes plenty of sense in mapping C.UTF-8 to > en_US.UTF-8, because most other UTF-8 locales are also mapped to > en_US.UTF-8, i.e. from X's perspective they're not actually > language-specific. On second look, this patch doesn't seem to be quite right, as it makes the en_US.UTF-8 compose sequences available in C.UTF-8 (which is not the case in the C locale). > More generally, there's the issue that Cygwin allows any combination > of language and charset, whereas X has a fixed list of permitted > combinations. Cygwin also supports many charsets that aren't supported > by X (and vice versa). In particular, X only supports a few of the > Windows/DOS codepages. But I guess unsupported locales will just have > to be a case of "don't do that"? Yes. Treating XSupportsLocale() returning false as a fatal error as the Xserver currently does is wrong, I would say, unless the application has very specific requirement, though. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/