Jerry James writes:
I can reproduce this bug. I'm trying to debug the problem now,
and my
XEmacs that is doing the debugging is complaining:
Alert: ("unchecked charset" #<charset ipa "IPA" "IPA"
"IPA
(International Phonetic Association)" 96 l2r cols=1 g1 final='0'
reg=[MuleIPA] 0x8a0cf>)
What does that mean?
It means that the Xft code is a horrible set of kludges, and one of
them failed.
Specifically, when the Xft routines get passed text to display, they
need to decide which font to use based on the charset because that is
how redisplay works. Redisplay expects a corresponding Mule charset,
but xft_find_charset_font receives as key a string already in Unicode.
I added a table-driven hack to get a Mule charset based on the
character code, and that alert means that we fell off the end of the
table. It's not particularly harmful, since Xft is well-behaved for
undefined characters. How an IPA character got into the Unicode
string in the first place is a bit worrying, though.
My guess is that it's a mechanism similar to the one that triggered
the crash Klaus experienced: several charsets were added to the list
of preloaded ones, and one of them has a case table that maps ASCII
into Turkish (or IPA, except that I don't think IPA should have a case
table?)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta