This removes those instances of keysyms which match <U03[0-6][0-9A-Fa-f]>,
where the matching keysym is used as a dead_key, and for which alternative
compose sequences exist.
Some of the UTF-8 Compose tables included combining_ keysyms in
the compose sequences as though they were dead symbols. This
is contrary to how combining characters are used in the UCS.
Therefore, those lines have been removed from the Compose tables.
There were also some combining_ keysyms as targets. As those
are not included in x11proto’s keysymdef.h, and as those do
exist there as Uxxxx keysyms, they are replaced with the Uxxxx
keysym names.
This addresses http://bugzilla.freedesktop.org/show_bug.cgi?id=5107
and is based on attachment 25644 by samuel.thibault@ens-lyon.org.
Signed-off-by: James Cloos <cloos@jhcloos.com>
Commit 97fc6babd4 "NLS: Add UTF-8 compose
file for Finnish" made fi_FI.UTF-8 use a broken empty XLC_LOCALE file.
This reverts it back to using the en_US.UTF-8 one.
On th_TH.UTF-8 locale, Thai XIM rejects all combining characters for GTK+ apps
that use X Input Method.
This is because GTK+ imxim immodule passes surrounding text in locale encoding,
which is UTF-8 for UTF-8 locales. But current Thai XIM in Xlib assumes the
multi-byte StringConversionText response for the StringConversionCallback to
always be TIS-620, by retrieving a single byte and using it as-is.
If the Thai XIM tries to convert the multi-byte text based on locale codeset
before using it, it will work again.
X.Org But 12759 <http://bugs.freedesktop.org/show_bug.cgi?id=12759>
Signed-off-by: Theppitak Karoonboonyanan <thep@linux.thai.net>
Signed-off-by: Julien Cristau <jcristau@debian.org>
The Thai XIM component in libx11 activated on 'th*' locales normally filters
input sequence according to orthographic rules. However, when NumLock/CapsLock
is on, this stops working. All sequences are passed through.
This is caused by missing masks in _XimThaiFilter(), which normally screens out
certain special keys from entering orthographic rules. Unfortunately, this
included events with NumLock/CapsLock on. Negating the masks from the check
allows the events to be tested by the rules.
X.Org Bug 12517 <http://bugs.freedesktop.org/show_bug.cgi?id=12517>
Signed-off-by: Theppitak Karoonboonyanan <thep@linux.thai.net>
Signed-off-by: Julien Cristau <jcristau@debian.org>
SCIM fails to commit Thai input characters on Thai locales, because it commits
string in compound text form, which was converted via
XwcTextListToTextProperty(). But the XLC_LOCALE for th_TH and th_TH.UTF-8
declares cs1's ct_encoding as TIS620-0:GR, which was commented out in
src/xlibi18n/lcCT.c default_ct_data, in favor of ISO8859-11 ESC sequence.
So, declaring cs1 as ISO8859-11:GR instead makes it work.
Besides, for th_TH.UTF-8, adding cs2 class with ISO10646-1 encoding also adds
support for UTF-8 input.
And, along discussion in the bug, a similar problem was found for fontset, too,
by causing delays on X apps startups on systems without tis620-0 fonts. This
is normally the case, as mkfontdir and mkfontscale generate iso8859-11 entries
by default for Thai X fonts. So, Thai fontset charset is also patched.
X.Org Bug 16475 <http://bugs.freedesktop.org/show_bug.cgi?id=16475>
Signed-off-by: Theppitak Karoonboonyanan <thep@linux.thai.net>
Signed-off-by: Julien Cristau <jcristau@debian.org>
This reverts commit 892b401d5a.
As Julien Cristau correctly points out, I misread the Compose file grammar
in modules/im/ximcp/imLcPrs.c, and those are keysyms, not comments, and
the keysym is named XK_masculine in keysymdef.h. This change is thus a
bug in the Solaris compose tables to be fixed, not an improvement to bring
upstream.
Matches the ordfeminine name used for the matching character,
and the ordmasculine name used in many font descriptions of the glyph.
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
This copy of Xrm.c is never compiled into the Xprint server any more, so
this old code-sharing #ifdef from the monolith tree isn't needed.
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
fi_FI was setting "x11thislocaledir" to en_US, with the result that its
locale data was written in that locale dir.
Signed-off-by: Chris Ball <cjb@laptop.org>
Since the Xlib multithreaded code checks the flags variable in _XFlushInt
to see if the other threads are done yet, it has to be marked volatile so
the compiler doesn't optimize out re-loading it on each trip through the
while loop and end up in an impossible-to-exit infinite loop of CPU chewing.
Part of fix for Sun bug 6409332: infinite loop in XFlushInt() on x86/32-bit
<http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6409332>
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
