Re: Solution for UTF-8 chars in the title bar?

Michal Jaegermann <michal harddata com> writes:
> If you are not using UTF-8 locales then you can hardly expect that
> UTF-8 characters will render properly.

Regardless of locale, the standard ICCCM window properties WM_NAME and
WM_ICON_NAME are encoded in something called compound text, which has
a large character set.  I don't know if it can represent all of
Unicode, but I have tested it with some weird characters without
finding a counterexample.

Considering this, I am not sure what was the motivation of the Gnome
developers for defining _NET_WM_NAME and _NET_WM_ICON_NAME in the EWMH
spec.  Those properties duplicate the functionality of the standard
properties but are encoded in UTF-8, again regardless of locale.

Hence, the X server has no problem with representing exotic characters
in window names, whether using the standard ICCCM properties or the
EWMH ones.  Problems may occur in a client when the desired window
name contains characters unrepresentable in the encoding used
internally by the client, typically the locale charset.  Then the
client may not be able to set the window name correctly.  Similar
problems may occur in the window manager if limitations of the wm
internal text encoding prevent correct reading of window names.

Unfortunately, some clients currently set the _NET_WM properties to
what they intend to be displayed but fail to set the ICCCM properties
to the corresponding values.  Support for the _NET_WM properties in
the wm would be useful to work around that.  Also, Sawfish may suffer
from the internal encoding problems mentioned in the previous
paragraph, depending on the locale Sawfish is running in.  The
Net_wm_properties patch has the potential to solve both problems by
using UTF-8 internally in Sawfish, regardless of locale.
Unfortunately, it botches support of the ICCCM properties by failing
to use the Xutf8 functions on those, instead going through the locale
charset and losing whatever characters are not representable in it.
This version should avoid that:
The non-X_HAVE_UTF8_STRING case is not well-tested though.  There characters
outside the current locale will be lost because direct conversion to UTF-8
is not available.

	Timo Korvola		<URL:>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]