Hi,
> 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).
Actually there are two implementation of the XLookupString in the Xlib
namely a 'core protocol' one and an XKB replacement for this subroutine.
And the XKB's XLookupString does this 'HACKing' from its birth.
You can read in the XKBlib.ps (which is 'X Consortium Standard') that
: 2.1.13 X Library Functions Affected by Xkb.
: ...
: When XKB is present, XLookupString is allowed, but not required, to return
: strings in character sets other than ISO Latin-1, depending on the current
: locale.
and
: 11.1.1 ForceLatin1Lookup
: If the ForceLatin1Lookup control is enabled, XLookupString only returns
: string using the Latin1 character set. If ForceLatin1Lookup is not enabled,
: XLookupString can return characters that are not in the Latin1 set.
: By default, this control is disabled, allowing characters outside of the Latin1
: set to be returned.
As for me I think this approach is more wise. It makes the XLookupString
not useless for non-Latin1 writing users but allows to return the previous
behaviour for those who need it.
> 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 ...
You know an Xserver interacts with an application's XLookupString sending
key events. And you know there are not any data in the XKey events that can
affect 'keysym to string' conversion in Xlib.
But there is a one difference between the XLookupString and
the X{mb|wc|utf8}LookupString family which also can interact with an 'Input
Server'.
Tht XFree's server doesn't have any Input Server by default but it seems
Solaris's server has.
In such case the XLookupString converts the keysym to a byte string
internally but the X{mb|utf8}Lookup sends events to the Input server which
converts them and sends the result back to the application. Thus if the
Solaris's Input Server converts them to UTF-8 but the application's
X{mb|utf8}Lookup doesn't recognize this fact there can be a double conversion
you saw.
I think a strace can help to prove/disprove my suspicions. Please attache
the strace to the running xev and press the keys
strace -p <xev's pid> -e read=3
If I'm right we will see an extra write/read after each key event reading.
And maybe the data which the application reads from Input Server will help
to guess why the X{}Lookup doesn't understand a server's output correctly.
--
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
