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/
