[Bug: 21.5-b28] Xft: characters picked from different fonts

Marcus Harnisch writes: "Should", maybe, but it doesn't. In a Mule build, XEmacs manages the fonts for each character set separately. The behavior you observe is expected until such time as the internal character set is Unicode. Even that is not a panacea, as according to recent reports on emacs-devel the unreleased Emacs 23 does the same thing, despite having a Unicode-based internal representation. I'm not exactly sure how this works because fontconfig basically assumes monolingual buffers and that programmers don't want to deal with it anyway, where XEmacs assumes multilingual ones and that users want control. There's a fundamental mismatch here that the contributors of Xft support chose not to address at all, and I haven't yet figured out how to untangle. My half-hearted effort is static struct charset_reporter charset_table[]; in src/objects-xlike-inc.c, but clearly that is failing dismally for you. Sorry! You could try (set-face-font 'default "monospace-12" nil nil 'remove) which kills off everything but the hardcoded fallbacks. If that doesn't work (it probably won't but it's easy to try), in your list I see both jit-ucs and Japanese charsets. So try editing src/objects-xlike-inc.c at around line 342 to specify that &Vcharset_japanese_jisx0208 corresponds to "en", not "ja", like this: { &Vcharset_japanese_jisx0208, "Japanese", "en" }, and add { &Vcurrent_jit_charset, "Misc Unicode", "en" }, then rebuild xemacs. If that works, I think I know how to fix it so that Japanese can still use Japanese fonts (I'm assuming you don't care ... if you do, make sure you keep a copy of your Japanese-capable xemacs installed somewhere!!) but I'd like to know that this kind of change actually works for you before messing with it. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta