I filed the following bug report at bugs.xfree86.org and was instructed to discuss it here. My application (the Ion window manager) currently can be compiled to use utf8 internally, but the Xutf8 routines are so broken that I've been experimenting with just using generic multibyte encodings (and perhaps later wchar_t for the few strings processing tasks, which are why I chose the utf8 route in the first place), and the Xmb routines. But they don't seem to work any better!
<http://bugs.xfree86.org/show_bug.cgi?id=877> --snip-- Problem 1 Font selection (from a fontset) in the Xutf8* string drawing routines does not work in a sane manner in any locale and neither does font selection in the Xmb/Wc* drawing routines in an UTF8 locale. Moreover, the Xmb and Xutf8 routines do not select fonts consistently in an UTF8 locale. Example 1. LC_CTYPE=fi_FI.UTF-8, user wants the base font to be -adobe-helvetica-medium-r-normal-*-12-*-*-*-*-*-iso8859-1. The same font _but with iso10646-1 encoding_ among some others fonts gets loaded (XCreateFontSet), guessed with the code available e.g. at <http://www.debian.org/doc/manuals/intro-i18n/ch-examples.en.html#s13.4>. (XCreateFontSet fails if only the user specified pattern is passed.) The Xmb routines never use any other fonts but the iso10646-1 helvetica that does not contain all characters, because fonts are selected based on first matching character set and iso10646 seems to be preferred. Studying the Xlib source code, apparnetly Xmb in UTF8 locale selects fonts by the order of fonts in the fontset, that does not match the order of fonts in the request pattern to XCreateFontSet. Shouldn't the pattern matter? Shouldn't the glyphs actually implemented in a font matter, in particular in case of iso10646 fonts? Example 2. Same as above, Xutf8 routines. These routines seem to prefer iso8859-1 encoding and indeed a fixed-width font with that encoding is in the fontset. But the user wanted helvetica! It seems Xutf8 routines select fonts from the fontset by a fixed list of encodings, filtered by the locale. Again, font select based on character set guess is wrong. Example 3. Same as above, remove iso10646-1 helvetica from system. Situtation is reversed. Xmb routines use a fixed-width font, Xutf8 routines helvetica. Problem 2 All the drawing routines also have the problem of stopping processing the string when an encoding is selected for which there is no font in the fontset, even if some font with other encoding might implement the wanted glyph. Once again, font selection should be based on the available fonts, not the first matching encoding and there's no need to skip the rest of the string even if a font can't be found. Problem 3 This is unrelated to the above two problems, may not necessarily be a bug in Xlib and I can only say of the situation under Debian/unstable, gnu libc 5.4.46. The problem is that if there are multiple encodings listed for otherwise the same locale in /etc/locale.gen and locale-gen has been used to generate whatever it does, libc mb routines always use the last encoding listed in that file while Xlib mb routines respect the LC_CTYPE setting. XSupportsLocale succeeds. While libc may not do the right thing here, it sets the environment and nl_langinfo(CODESET) can be used to obtain the encoding expected by the libc mb routines. -- Tuomo _______________________________________________ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
