GenericEvent cannot be selected for in the core event masks and they must
thus be treated like extension events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
GenericEvents have no fixed position for the window, so they must be treated
like extension events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The replaces the instances of keysyms which match <U03[0-6][0-9A-Fa-f]>,
where the keysym is used as a dead_key, with an actual dead_key symbol.
The only remaining instances of UCS combining characters in the
compose sequences are of U0338 COMBINING LONG SOLIDUS OVERLAY
used as a suffix in Multi_key-initiated sequences to create
mathematics characters such as ∉ U+2209 NOT AN ELEMENT OF
from ∈ U+2208 ELEMENT OF.
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>
