Re: Solution. was:[I18n]XFree86 Xutf8LookupString BUG with Solarix X server.
IP And I still doubt is the ASCII characters a special case or they IP should be processed in the same way. From your description only, it does indeed sound like there's no reason to treat ASCII separately. If you've got the time and inclination to do so, you could wait until 4.3.0 is out, then submit a patch that removes the special-casing and see whether any complaints come it. Juliusz ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: Solution. was:[I18n]XFree86 Xutf8LookupString BUG with Solarix X server.
Thanks for the fast bug fix. I hope, RedHat/Suse/etc. will fix this in
their RPMs *very soon*, otherwise the UTF-8 locales remain completely
unuseable for everyone on an X server without XKBD (e.g., Solaris).
Ivan Pascal wrote on 2002-11-29 12:46 UTC:
But under the UTF-8 locale XLookupString returns two (and more) chars
for non-ascii keysyms. And X{mb|wc|utf8}LookupString mistakely converted
them to UTF-8 one more time.
Wasn't Xutf8LookupString supposed to be guaranteed to be locale
encoding *independent*? So why does it have to be implemented on top of
the (apparently) locale-dependent XLookupString? Sounds not entirely
kosher ...
the X{mb|wc|utf8}LookupString family has a checking which discards
non-ascii char outputed by XLookupString if it is only one
Why is it necessary to distinguish between ASCII and non-ASCII
characters?
xc/lib/X11/XKB.c
Markus
--
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org, WWW: http://www.cl.cam.ac.uk/~mgk25/
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
Re: Solution. was:[I18n]XFree86 Xutf8LookupString BUG with Solarix X server.
Wow. Could you please explain what's going on here? Juliusz ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: Solution. was:[I18n]XFree86 Xutf8LookupString BUG with Solarix X server.
Juliusz Chroboczek wrote:
Wow. Could you please explain what's going on here?
In short: the mechanism which switches XLookupString to 'Latin1 only' mode
was broken.
X{mb|wc|utf8}LookupString calls XLookupString with this mode and then
deals with its output. The bug never appeared with non-multibyte encodings
becouse the X{mb|wc|utf8}LookupString family has a checking which discards
non-ascii char outputed by XLookupString if it is only one (becouse even
a Latin1 char is useless for X{mb|wc|utf8}LookupString which converts keysyms
to the char string in own way).
But under the UTF-8 locale XLookupString returns two (and more) chars
for non-ascii keysyms. And X{mb|wc|utf8}LookupString mistakely converted
them to UTF-8 one more time.
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]XFree86 Xutf8LookupString BUG with Solarix X server
'A knot!' said Alice. 'Oh, do let me help to undo it!' Could you please put an xscope dump on the web somewhere ? Thanks, Juliusz P.S. You'll find xscope on http://keithp.com/~keithp/download/ . ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]XFree86 Xutf8LookupString BUG with Solarix X server
Juliusz Chroboczek wrote on 2002-11-28 11:36 UTC: 'A knot!' said Alice. 'Oh, do let me help to undo it!' Could you please put an xscope dump on the web somewhere ? Thanks! I didn't know about xscope. The requested dump is now on http://www.cl.cam.ac.uk/~mgk25/ucs/xev-adiaeresis-utf8.txt including a full description of what I did to get the log. Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: http://www.cl.cam.ac.uk/~mgk25/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Solution. was:[I18n]XFree86 Xutf8LookupString BUG with Solarix X server.
Markus Kuhn wrote:
The requested dump is now on
http://www.cl.cam.ac.uk/~mgk25/ucs/xev-adiaeresis-utf8.txt
including a full description of what I did to get the log.
I have found the bug.
Honestly speaking it's my fault. The changes cause this bug was made more
than two years ago but the bug appears only now.
The attached patch solves the problem.
P.S. I already sent the patch to the patch mail list (seq: 5513).
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
--- xc/lib/X11/XKB.c.orig Fri Nov 29 11:13:59 2002
+++ xc/lib/X11/XKB.cFri Nov 29 11:16:16 2002
@@ -417,9 +417,10 @@
unsigned values;
#endif
{
-if ((dpy-flags XlibDisplayNoXkb) ||
- (!dpy-xkb_info !XkbUseExtension(dpy,NULL,NULL)))
- return False;
+ if (!dpy-xkb_info)
+ XkbUseExtension(dpy,NULL,NULL);
+ if (!dpy-xkb_info)
+ return 0;
affect= XkbLC_AllControls;
dpy-xkb_info-xlib_ctrls= ~affect;
dpy-xkb_info-xlib_ctrls|= (affectvalues);
@@ -434,9 +435,10 @@
Display * dpy;
#endif
{
-if ((dpy-flags XlibDisplayNoXkb) ||
- (!dpy-xkb_info !XkbUseExtension(dpy,NULL,NULL)))
- return 0;
+ if (!dpy-xkb_info)
+ XkbUseExtension(dpy,NULL,NULL);
+ if (!dpy-xkb_info)
+ return 0;
return dpy-xkb_info-xlib_ctrls;
}
[I18n]XFree86 Xutf8LookupString BUG with Solarix X server
I think I have run into a serious bug with XFree86's Xutf8LookupString
implementation. It occurs when the client runs under XFree86 4.[12], but
the X server is for example Solaris 5.8
vendor string:Sun Microsystems, Inc.
vendor release number:6410
(also occurs on Solaris 5.7). It does but not occur when the X server is
XFree86 4.1.
i) To reproduce the problem, start an X client in the following
environment:
- use a UTF-8 locale (e.g., LC_CTYPE=en_GB.UTF-8)
- use an XFree86 4.1 or 4.2 Linux system (tested on Red Hat 7.2,
Red Hat 8.0 and SuSE 8.1)
- point $DISPLAY to a Sun Solaris X server
Then press on the Sun X server a key that causes the keysym
adiaeresis to be sent to the above client. The client will
receive from the various key string lookup functions the
following strings (as displayed in a UTF-8 xterm, hex values
provided for clarity):
XLookupString gives 2 bytes: ä (c3 a4)
XmbLookupString gives 4 bytes: ä (c3 83 c2 a4)
Xutf8LookupString gives 4 bytes: ä (c3 83 c2 a4)
There are two problems, the first critical, the second dubious:
a) CRITICAL: Both X{mb,utf8}LookupString output the same broken
byte sequence that one gets if one sends the UTF-8 sequence for
ä (c3 a4) erroneously through an ISO 8859-1 - UTF-8 converter,
i.e. c3 83 c2 a4.
b) DUBIOUS: XLookupString is according to the manual supposed to *always*
return ISO 8859-1 strings (just like STRING atoms always use ISO 8859-1),
but here it actually returns text in the locale's multibyte encoding.
(This is ok, if we can agree to change the libX11 C API
definition accordingly, but it looks suspiciously like someone has
been HACKing without respect for the API spec).
ii) If the same setup as in i) is used, but the locale of the client
replaced with an ISO 8859-1 locale (e.g., en_GB), then the result looks
correct (as displayed in an ISO 8859-1 xterm):
XLookupString gives 1 bytes: ä (e4)
XmbLookupString gives 1 bytes: ä (e4)
Xutf8LookupString gives 2 bytes: ä (c3 a4)
iii) Similarly, if the same setup as in i) is used, but the X server is
XFree86 4 with e.g.
vendor string:The XFree86 Project, Inc
vendor release number:4010
XFree86 version: 4.1.0
at least the CRITICAL problem is gone (as displayed in a UTF-8 xterm):
XLookupString gives 2 bytes: ä (c3 a4)
XmbLookupString gives 2 bytes: ä (c3 a4)
Xutf8LookupString gives 2 bytes: ä (c3 a4)
All the above output is from a patched version of xev that outputs
the strings from all three lookup functions.
This bug report distills my findings reported here earlier that
UTF-8 keyboard support fails from a Sun X server with the xterm and
emacs implementations in Red Hat 8.0.
Any ideas or reports of reproduceability would be welcome. This might
turn into a high priority problem, as breaking the X protocol this way
might be a major UTF-8 show stopper. Please have a look at it ...
Markus
--
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org, WWW: http://www.cl.cam.ac.uk/~mgk25/
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]XFree86 Xutf8LookupString BUG with Solarix X server
Markus Kuhn [EMAIL PROTECTED] writes: I think I have run into a serious bug with XFree86's Xutf8LookupString implementation. It occurs when the client runs under XFree86 4.[12], but the X server is for example Solaris 5.8 vendor string:Sun Microsystems, Inc. vendor release number:6410 (also occurs on Solaris 5.7). It does but not occur when the X server is XFree86 4.1. You migth want to try disabling XKB for the XFree86 server; the XKB/non-XKB difference is about the only thing I can see where the server would matter for this. Regards, Owen ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
