Markus Kuhn <[EMAIL PROTECTED]> writes:
> The keyboard coding system is already at UTF-8, so that was not the
> problem.
>
> I just noticed to my amasement that in our RH8 test installation, xterm
> has the exact same problem that I reported for emacs: If I type the
> keysym leftsinglequotemark, then xev receives it correctly, says
> "XLookupString gives 3 characters" and also produces the correct
> UTF-8 multibyte sequence, such that xterm shows the right glyph for this
> keysym.
>
> But wait a second:
>
> This suggests that something dramatic has changed with XLookupString
> between Red Hat 7.2 and Red Hat 8. XLookupString is according to the
> manual page supposed to return *only* ISO 8859-1 strings, independent of
> the locale, and it seems now that someone has hacked this in RH8 in
> violation of the X API to deliver UTF-8 (which should only come out of
> XmbLookupString and Xutf8LookupString).
>
> If I type the same leftsinglequotemark in the xterm window, then the
> application sees c3 a2 c2 80 c2 98, which is the result of sending the
> UTF-8 representation of leftsinglequotemark through an ISO 8859-1 to
> Latin-1 converter. This makes sense, because xterm correctly expects out
> of XLookupString only ISO 8859-1 bytes and therefore converts them to
> UTF-8 if it is in UTF-8 mode.
>
> This looks bad ...
I haven't investigated in detail, but this doesn't make a lot
of sense to me. Presumably xterm is using XmbLookupString, since
iso-8859-2 compose sequences work in iso-8859-2 locales, etc.
Regards,
Owen
--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
