Stephen> I'll pick up a release tarball and update all my packages Stephen> tomorrow or so and see if that fixes this. Package update is done by FTP and hand-unpack; in the process, I noticed that tar: lisp/fsf-compat/thingatpt.el: Could not create file: Permission denied tar: lisp/mule-base/ethiopic.EL: Could not create file: Permission denied tar: lisp/mule-base/ethio-util.EL: Could not create file: Permission denied and that was because they were read-only. Do the package-get*.el utilities check these conditions? In mule-base-1.22-pkg.tar.gz fsf-compat-1.02-pkg.tar.gz which I assume are current (latest in /pub/xemacs/packages/), the permissions are now -r--r--r-- 1 steve steve 65216 Feb 23 1998 lisp/mule-base/ethio-util.EL -r--r--r-- 1 steve steve 4119 Feb 23 1998 lisp/mule-base/ethiopic.EL -rw-r--r-- 1 steve steve 12996 May 7 13:00 lisp/fsf-compat/thingatpt.el An update for vm (to 1.13) was promised but isn't there, am I looking in the wrong place? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +1 (298) 53-5091

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

SJT> The poor selection of kanji fonts occurs with several 21.0 SJT> betas (Norwegian and Poitou at least). mb> Does it work to set the fonts in Lisp? mb> (set-face-font 'default OK, this works (with fonts that I actually have, of course). Um, where did the mule-fonts tag go? Doesn't it matter? mb> If so, it is merely a matter of convenience and documentation mb> that the same functionality is not accessible via X resources. X resources are not the point; you and I can work with them or around them. The issue is that on my system, at least, any attempt to alter _any_ faces, font or size of any charset, via the Options menu results in completely unusable kanji fonts. These cannot be changed _at all_ outside of Lisp AFAIK, short of restarting XEmacs. That is not acceptable to ordinary users, and thus a showstopper IMO. Don't release a Mule XEmacs in this state, please. Also, the fact that the initialization code produces completely different results from the normal operation code bothers me; I'm not sufficiently well-informed to know whether it's something that must (or even can) be fixed or not. But I don't like it. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +1 (298) 53-5091

mb> Does it work to set the fonts in Lisp? mb> (set-face-font 'default SJT> OK, this works (with fonts that I actually have, of SJT> course). The bottom line is that the Options menu really only works in a Latin-1 world, where the concept of a single font actually makes sense. (Although, in principle, the CDE fonts should provide a unified solution to this mess). Mule users or syadmins should figure out the (set-face-font) incantation and put that in their .emacs or site-start.el. SJT> On second look, no it doesn't. Further experimentation shows that SJT> XEmacs doesn't always use all of the specified fonts and the Options SJT> menu ends up in a state that may not correspond to _any_ of the SJT> visible fonts. (I haven't been able to replicate that last. But SJT> using lucidatypewriter as my iso8859-1 font in (set-face-font ...) is SJT> consistently ignored---even if current Options | Font setting is SJT> lucidatypewriter (it gets set to courier or fixed). Grrrr!) Realize that the Option's menu's job is impossibly difficult in the presence of multiple fonts. That's not to say the implementation can't be improved. SJT> So what we have is a workaround that allows me to get back to a SJT> reasonable state---but not close to optimal. SJT> Probably I could deal with this if I really understood faces. But I SJT> doubt that many users do, well enough to get what they want. Martin

>>>>> "mb" == Martin Buchholz <martin(a)xemacs.org&gt; writes: SJT> The poor selection of kanji fonts occurs with several 21.0 SJT> betas (Norwegian and Poitou at least). mb> Does it work to set the fonts in Lisp? mb> (set-face-font 'default SJT> OK, this works (with fonts that I actually have, of course). SJT> Um, where did the mule-fonts tag go? Doesn't it matter? The tag is just a method to allow you to manipulate multiple fonts as a set. Personally specified fonts should probably not use a tag. mb> If so, it is merely a matter of convenience and documentation mb> that the same functionality is not accessible via X resources. SJT> X resources are not the point; you and I can work with them or around SJT> them. SJT> The issue is that on my system, at least, any attempt to alter _any_ SJT> faces, font or size of any charset, via the Options menu results in SJT> completely unusable kanji fonts. These cannot be changed _at all_ SJT> outside of Lisp AFAIK, short of restarting XEmacs. SJT> That is not acceptable to ordinary users, and thus a showstopper IMO. SJT> Don't release a Mule XEmacs in this state, please. XEmacs has been in this state for a while. The whole font problem in XEmacs is really tough to fix, and should not be fixed for 21.0. SJT> Also, the fact that the initialization code produces completely SJT> different results from the normal operation code bothers me; I'm not SJT> sufficiently well-informed to know whether it's something that must SJT> (or even can) be fixed or not. But I don't like it. Code contributions are always welcome. Maybe some design work can be snarfed from other operating systems or applications. Martin