Glynn Clements writes:
XftDrawString8() assumes that the text is ISO-8859-1 (specifically,
treats each byte as a unicode codepoint). If you have text in some
other encoding, you need to convert it to unicode yourself.
To be precise, XftFooN() for N=8, N=16, or N=32 treats text as encoded
in Unicode, with each N bits treated as an (unsigned) nonnegative
integer character code. While XftFooUtfN() for N=8 or N=16 is a
Obviously, using XftDrawStringUtf8 will fail if the text isn't
UTF-8. While nothing prevents you from specifying menu labels in UTF-8
regardless of the locale's encoding, editing the app-defaults file is
likely to be a pain if it contains text in multiple encodings.
There's no locale to worry about; this is a multilingualized, not an
internationalized, feature. Another way to look at it is that this is
internal XEmacs data, and is in whatever encoding is convenient for
loading as a resource, just as a C file would be. IMO, that's X
Compound Text for the legacy XFontSet approach to multilingualization,
and UTF-8 for Xft.
The only real problem with switching to UTF-8 globally (in both data
files and Lisp files) is 21.4's lack of support for Unicode. Perhaps
Julian will fix that for us.
The other problem with multilingual widgets (the tabs visibly have the
same problem, and progress gauges would too if they were M17N at all)
is font selection. This really ought to be done via a face, but
native widgets currently don't play well with faces, while the kludgy
XEmacs widgets like the toolbar (which is actually a gadget drawn
directly by the Emacs text widget, as are the gutters themselves) do a
better job of honoring face specifications, but they're kludgy.
XEmacs-Beta mailing list