Description of problem: Starting xemacs in a gnome-terminal gives: Warning: Cannot convert string "-*-helvetica-bold-r-*-*-*-120-*-*-*-*-*-*" to type FontStruct Warning: Missing charsets in String to FontSet conversion In a *Warnings* buffer it shows: (1) (font/warning) xemacs: couldn't deduce a bold-italic version of the font "-*-*-medium-r-*-*-*-120-*-*-c-*-*-*". Please specify X resources to make the bold-italic face visually distinguishable from the default face. For example, you could add one of the following to $HOME/Emacs: XEmacs.bold-italic.attributeFont: -dt-*-medium-i-* or XEmacs.bold-italic.attributeForeground: hotpink (2) (font/warning) xemacs: couldn't deduce an italic version of the font "-*-*-medium-r-*-*-*-120-*-*-c-*-*-*". Please specify X resources to make the italic face visually distinguishable from the default face. For example, you could add one of the following to $HOME/Emacs: XEmacs.italic.attributeFont: -dt-*-medium-i-* or XEmacs.italic.attributeForeground: hotpink (3) (font/warning) xemacs: couldn't deduce a bold version of the font "-*-*-medium-r-*-*-*-120-*-*-c-*-*-*". Please specify X resources to make the bold face visually distinguishable from the default face. For example, you could add one of the following to $HOME/Emacs: XEmacs.bold.attributeFont: -dt-*-medium-i-* or XEmacs.bold.attributeForeground: hotpink Starting e.g. MH-E complains about a lot of other fonts. Version-Release number of selected component (if applicable): xemacs-21.5.28-9.fc10.x86_64 How reproducible: Always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
See also bug 478370. I don't have a F-10 or Rawhide box available, and I don't see any problems on F-9, so it might take some time until this gets more attention (from me). Asking upstream on the xemacs-beta mailing list could provide some hints/answers.
I believe this is due to the font handling update in rawhide, and probably afects many X-based packages. E.g., xterm run from a gnome-terminal says: Warning: Cannot convert string "nil2" to type FontStruct xlogo says: Warning: Cannot convert string "xlogo32" to type Pixmap xfontsel says: Warning: Missing charsets in String to FontSet conversion and has only 4 fonts to offer.
This is definitely a Xorg font problem, not of xemacs' doing. E.g. xfig says in its error window (organigrama.fig uses Helvetica bold at 14 points): Can't load font: 8x13bold, using 6x13 --------------------- File organigrama.fig: Can't find -urw-nimbus sans l-bold-r-normal--16-*-*-*-*-*-ISO8859-*, using 6x13 Can't find -urw-nimbus sans l-bold-r-normal--13-*-*-*-*-*-ISO8859-*, using 6x13 On the gnome-terminal where I run it it says: Warning: Cannot convert string "7x13bold" to type FontStruct
Is it related to this : http://www.mail-archive.com/xorg@lists.freedesktop.org/msg03141.html ? In my case, downgrading to xorg-x11-server-1.5.3 worked just fine, so I think the problem is specific to version 1.5.99 of xorg-x11-server.
Humm... the message cited looks for /usr/share/fonts/X11/, which certainly doesn't exist here. Is there any way (short of downlading the RPM and peeking inside) of knowing if that is the difference between servers? Also, I was asked in private email if restarting xfs makes a difference. There is no xfs here on this machine. On another, older rawhide install (less cared for, sorry) there is xfs, and restarting that makes no difference. There there isn't a /usr/share/fonts/X11/ either.
Right, if no font path is defined in xorg.conf, Xorg will defaults to "catalogue:/etc/X11/fontpath.d,built-ins". With Xorg 1.5.3, the Xorg.log contains : (==) No FontPath specified. Using compiled-in default. (==) FontPath set to: catalogue:/etc/X11/fontpath.d, built-ins and with Xorg-1.5.99.901, the Xorg.log contains : (==) No FontPath specified. Using compiled-in default. (==) FontPath set to: built-ins which means that catalogue:/etc/X11/fontpath.d, the place where all legacy fonts are symlinked, is probably simply silently ignored. And manually forcing the FontPath in xorg.conf like that : Section "Files" FontPath "catalogue:/etc/X11/fontpath.d" FontPath "built-ins" EndSection generates an error with 1.5.99-901 : [dix] Could not init font path element catalogue:/etc/X11/fontpath.d, removing from list! I downgraded my xorg packages to these versions, using Fedora 10 packages: xorg-x11-server-Xorg-1.5.3-6.fc10.i386 xorg-x11-server-common-1.5.3-6.fc10.i386 and also these packages to satisfy dependencies requirements: xorg-x11-drv-mouse-1.3.0-2.fc9.i386 xorg-x11-drv-keyboard-1.3.0-3.fc9.i386 xorg-x11-drv-trident-1.3.0-1.fc9.i386 the solution proposed in the xorg-list thread suggests to rebuild xorg-x11-server with configure --disable-builtin-fonts. I didn't test this possibility.
If you remove /etc/X11/xorg.conf (or move it somewhere away of X's reach) and restart Xorg, does xemacs work? Could you post us /var/log/Xorg.0.log from this attempt (even if it doesn't help)?
Created attachment 328989 [details] Xorg.0.log with broken bitmap fonts
Sorry, and does it work?
X per se works, bitmap fonts do not.
And the problem is basically this: $ xlsfonts -misc-fixed-medium-r-semicondensed--0-0-75-75-c-0-iso8859-1 -misc-fixed-medium-r-semicondensed--13-100-100-100-c-60-iso8859-1 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1 6x13 cursor fixed Which is not nearly the number of fonts I'd expect on a system that has japanese-bitmap-fonts, xorg-x11-fonts-ISO8859-1-75dpi and xorg-x11-fonts-ISO8859-1-100dpi installed, among others.
Created attachment 329047 [details] Requested Xorg.0.log (In reply to comment #7) > If you remove /etc/X11/xorg.conf (or move it somewhere away of X's reach) and > restart Xorg, does xemacs work? Could you post us /var/log/Xorg.0.log from this > attempt (even if it doesn't help)? Haven't had /etc/X11/xorg.conf for quite some time here.
From my yesterday IRC chat: > kem: yeah, i think this is actually a server bug where it disallows font paths to work > kem: i think dan nicholson is on the right path... http://thread.gmane.org/gmane.linux.redhat.fedora.devel/102532/focus=102589 > mcepl: is it builtin fonts or builtin rasterizer? > mcepl: and does it matter? > kem: it's that if you turn on BUILTIN_FONTS, the code would only register the builtin fonts, and not let you have external font files at all > mcepl: why would we do it? > kem: so it effectively disabled all external fontpaths specified in the xorg.conf file -- that's a bug > kem: it was fixed upstream, but i'm guessing that hasn't gone into the release-candidate yet Switching to ASSIGNED
*** Bug 480159 has been marked as a duplicate of this bug. ***
Created attachment 329649 [details] Patch restoring core fonts functionality xorg git master actually has a patch for this, here is a slightly modified (so that it will apply cleanly) version of this patch, I've tested this and it restores core-fonts functionality for me.
Created attachment 329650 [details] Updated mtrr patch to fix compile with latest kernels And here is an updated mtrr patch to fix compile with the very latest kernels.
or did this already get fixed?
It has, my patch has been included in recent Xorg builds by airlied, but he did not close this, so I'll close it now.
Hopefully this is the correct bug to add onto? though closed. F13 XFCE "xterm: cannot load font -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1" Currently: xorg-x11-server-utils-7.4-16.fc13.i686 xorg-x11-server-common-1.7.99.902-3.20100319.fc13.i686 xorg-x11-server-Xorg-1.7.99.902-3.20100319.fc13.i686 bash-4.1$ xlsfonts | grep fixed -misc-fixed-medium-r-semicondensed--0-0-75-75-c-0-iso8859-1 -misc-fixed-medium-r-semicondensed--13-100-100-100-c-60-iso8859-1 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1 fixed ucs-miscfixed-fonts-0.3-5.fc13.noarch
Never mind found the missing font in: xorg-x11-fonts-misc