On Sat, 18 Oct 2003, Per Olofsson wrote: > So maybe the problem is related to the fact that Ion uses the Xutf8 > functions which are less used in other programs (?) and therefore are more > likely to contain bugs.
I've read some mailing list discussions now, and it seems like the Xutf8 functions are quite controversial. For example: [1]"The commit was made during the flame war^W^Wdiscussion." [2]"I can't speak for XFree86, but I can speak for X.Org, and the Xutf8* APIs are certainly not part of standard X, nor were they likely ever to be. I regret that they were so precipitously put into the XFree86 release, [...]" Maybe this could explain why the Xutf8 functions are buggy. The XFree86 developers have to keep them to avoid breaking the ABI, but they may not be very inclined to test and maintain them properly. I really don't know what the right thing to do is. Some people argue that it is wrong to hard-code a specific character set such as UTF-8 as there might be some other that is preferable in the future. Still, this is the approach that many takes, like GTK and M$ for example, and Ion of course. The Xmb functions do incur a certain overhead because of the uncertainity of which character set is used, and I thought the idea of Unicode/UCS was to get rid of all these different character sets and stop worrying. But the Xutf functions are non-standard and possibly only half-heartedly supported. The only alternative I find except Xmb* is XDrawString16, which seems even more problematic and will never support more than 16-bit characters. Maybe I should get around to implement that Xft drawing engine after all, now that the font stuff is separated from the rest. [1] http://archives.neohapsis.com/archives/openbsd/2000-12/0764.html [2] http://archives.neohapsis.com/archives/openbsd/2000-12/0761.html
