Kanji font selection (Mule showstopper?)

The poor selection of kanji fonts occurs with several 21.0 betas (Norwegian and Poitou at least). I do get the blanching you can see below in both Norwegian and Poitou; I just never tried to reset size recently since the default was satisfactory, I guess. I'm pretty sure I didn't get it in Uzbek Black but I don't have one available right to hand. It makes XEmacs unusable when it manifests, because it cannot be recovered without restarting XEmacs as far as I can tell. It does not occur in XEmacs 20.4 on the same machine with the same X server. On my machine I can reproduce it on both Norwegian and Poitou with bash$ LANG=ja_JP.euc xemacs -vanilla M-x xemacs-splash-buffer => [Options | Size | 14] => [Options | Size | 12] => After that, the kanji font does not change no matter what size or font is set from the Options menu. I've tried about a dozen random combinations. I set the LANG in order to get the Japanese-localized splash-buffer, the bug manifests also with LANG void. My X configuration: No emacs-related X resources. tanko# fgrep jisx0208 /usr/X11R6/lib/X11/fonts/misc/fonts.dir jiskan24.pcf.gz -jis-fixed-medium-r-normal--24-230-75-75-c-240-jisx0208.1983-0 jiskan16.pcf.gz -jis-fixed-medium-r-normal--16-150-75-75-c-160-jisx0208.1983-0 k14.pcf.gz -misc-fixed-medium-r-normal--14-130-75-75-c-140-jisx0208.1983-0 tanko# fgrep jisx0208 /usr/X11R6/lib/X11/fonts/misc/fonts.alias k14 -misc-fixed-medium-r-normal--14-*-*-*-*-*-jisx0208.1983-0 kanji16 -jis-fixed-medium-r-normal--16-*-*-*-*-*-jisx0208.1983-0 kanji24 -jis-fixed-medium-r-normal--24-*-*-*-*-*-jisx0208.1983-0 -jis-fixed-medium-r-normal--16-110-100-100-c-160-jisx0208.1983-0 -jis-fixed-medium-r-normal--16-150-75-75-c-160-jisx0208.1983-0 -jis-fixed-medium-r-normal--24-170-100-100-c-240-jisx0208.1983-0 -jis-fixed-medium-r-normal--24-230-75-75-c-240-jisx0208.1983-0 Font Path: /usr/X11R6/lib/X11/fonts/misc/, /usr/X11R6/lib/X11/fonts/100dpi/:unscaled, /usr/X11R6/lib/X11/fonts/Type1/, /usr/X11R6/lib/X11/fonts/Speedo/, /usr/X11R6/lib/X11/fonts/100dpi/ Except for the :unscaled 100dpi fonts, this is the standard setup on at least two Linux distributions. me> As near as I can tell, XEmacs is now picking one medium kanji me> font and one bold kanji font (of different sizes) and using me> them at all sizes of the default face (or whatever it is that me> is changed by Options | Sizes). me> It is not clear to me how kanji fonts/sizes can be changed via me> customize faces or Options | Fonts/Sizes, and that is clearly me> unacceptable, if it's not somehow my fault. Poking around a bit, AFAICT Mule fonts are pure sorcery, buried well below the Lisp level. From x-faces.el: ;; We default to looking for iso8859 fonts. Using a wildcard for the I don't understand this at all; the whole Lisp-level interface seems to assume you can set iso8859-1 (I think I can include the "-1") fonts and get reasonable selections for everything else. Ie, it doesn't make much sense to specify a non-iso8859-1 font (especially since that would be extremely restrictive on the available sizes if you specify an Aisan font). ;; encoding would be bad, because that can cause English speakers to get ;; Kanji fonts by default. It is safe to assume that people using a ;; language other than English have both set $LANG, and have specified Not safe. I know several people besides myself who don't (this is Mule, after all; it should work _without_ setting LANG, which has bad effects for some combinations of languages). In any case, as seen above, setting LANG doesn't affect this bug. ;; their `font' and `fontList' resources. I don't. Still, why specify fontList when you only have one of each? :-) I don't see how this would fix my problem, anyway, since the font(List)? usually wildcards sizes IIRC. And these resources are deprecated anyway, aren't they, with preference given to the attributeFont resources? In fact, fontList is available only if you configure --with-motif, right? You can use font sets with --with-xfs in X11R6 (but not X11R5 IIRC), but that's different and I don't know that those resources are accessible (certainly not documented). Anyway, the behavior suggests that somebody tweaked font selection in some way which has evil effects on charsets with few fonts with a sparse selection of sizes. The fonts that XEmacs now insists on using at all sizes available through the menu are scaled bitmaps :-( It even substitutes the scaled bitmap at the wrong size for the design size of the bitmap!! This would be fixable by turning off bitmap scaling I guess, but I don't want to do that. Typically in XEmacs 20.4 there is a legible scaling of the bitmap within two pixels of any given pixel size. OK, Ben, I'm with you; I want an XEmacs that just fuckin' works, too. It's going to be a while before I learn enough to think about messing with this code though. me> The care and feeding of Mule fonts doesn't seem to be me> documented in Info at all :-( I'll look into doing something me> about that. This I'll get on right away. I did find *one* reference to the fontList resource, but it was about Motif menubars. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +1 (298) 53-5091