Bug 478999 (nooldfonts)

Summary: old-style bitmap fonts not provided by X server
Product: [Fedora] Fedora Reporter: Horst H. von Brand <vonbrand>
Component: xorg-x11-serverAssignee: Adam Jackson <ajax>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: medium    
Version: rawhideCC: atu.guda, dcantrell, fabrice, hdegoede, mcepl, petersen, redhat-bugzilla, sysoutfran, twoerner, ville.skytta, xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-02-09 09:49:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 476773    
Attachments:
Description Flags
Xorg.0.log with broken bitmap fonts
none
Requested Xorg.0.log
none
Patch restoring core fonts functionality
none
Updated mtrr patch to fix compile with latest kernels none

Description Horst H. von Brand 2009-01-06 12:52:39 UTC
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:

Comment 1 Ville Skyttä 2009-01-06 13:50:21 UTC
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.

Comment 2 Horst H. von Brand 2009-01-06 14:43:39 UTC
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.

Comment 3 Horst H. von Brand 2009-01-12 20:10:50 UTC
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

Comment 4 Fabrice Bellet 2009-01-13 16:31:27 UTC
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.

Comment 5 Horst H. von Brand 2009-01-13 19:31:29 UTC
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.

Comment 6 Fabrice Bellet 2009-01-13 20:40:26 UTC
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.

Comment 7 Matěj Cepl 2009-01-13 23:58:03 UTC
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)?

Comment 8 Ralf Ertzinger 2009-01-14 13:58:35 UTC
Created attachment 328989 [details]
Xorg.0.log with broken bitmap fonts

Comment 9 Matěj Cepl 2009-01-14 15:01:27 UTC
Sorry, and does it work?

Comment 10 Ralf Ertzinger 2009-01-14 16:39:30 UTC
X per se works, bitmap fonts do not.

Comment 11 Ralf Ertzinger 2009-01-14 17:38:00 UTC
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.

Comment 12 Horst H. von Brand 2009-01-14 21:23:17 UTC
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.

Comment 13 Matěj Cepl 2009-01-15 14:57:30 UTC
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

Comment 14 Matěj Cepl 2009-01-15 22:17:09 UTC
*** Bug 480159 has been marked as a duplicate of this bug. ***

Comment 15 Hans de Goede 2009-01-21 20:12:17 UTC
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.

Comment 16 Hans de Goede 2009-01-21 20:13:19 UTC
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.

Comment 17 Jens Petersen 2009-02-09 09:44:47 UTC
or did this already get fixed?

Comment 18 Hans de Goede 2009-02-09 09:49:37 UTC
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.

Comment 19 Frank Murphy 2010-04-06 17:23:47 UTC
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

Comment 20 Frank Murphy 2010-04-07 08:17:07 UTC
Never mind found the missing font in:
xorg-x11-fonts-misc