[Bug 52163] Scalable bitmap font names reported but not usable after failed XSetFontPath() call

[vmhacker]

Public bug reported:

This is either a bug in libx11-6, the xorg.conf file, or gnome-settings-
daemon.

In both dapper and breezy, the default session starts the gnome-
settings-daemon.  This program initializes by first creating the files
~/.gnome2/share/{cursor-fonts,fonts} in the user's home directory.  It
then runs mkfontdir on both directories, and uses XSetFontPath() to add
the cursor-fonts directory to the head of the X server's font path, and
the fonts directory to the tail fo the path.

By default, there are no font files in either directory.  Between
revision 1.1 and 1.2 (root=cvs.freedesktop.org:/cvs/xorg, repository=xc)
the behavior of XSetFontPath() changed from "reject directories with
fonts.dir files containing at least 1 bad entry" to "accept directories
if at least one good entry exists in the fonts.dir file".  The subtle
difference is that a fonts.dir file that contains simply "0" (i.e., and
empty font directory) is rejected in the more recent revisions and
accepted in the earlier ones.

When the gnome-settings-daemon tries to change the X server's font path,
the server sends a BadValue error (because the new directories are not
valid) and gnome-settings-daemon silently ignores the error event.

One of the first things the server does in response to the
XSetFontPath() client message is to run the set_path_hook and clear the
FontFileBitmapSources cache (lib/font/fontfile/bitsource.c).  However,
it appears that this only partially reset the server's view of the
available fonts.  The server still returns scalable bitmap font names in
response to a ListFonts request, but trying to realize a concrete
instance of one of these scalable bitmap names results in an error.


In order to reproduce the X portion of the problem, all you need is to
have both the scaled and unscaled paths to some bitmap font directory
(e.g., /usr/share/X11/fonts/100dpi) in the font path, and then execute a
bad XSetFontPath() request.  E.g.:

 #> xset +fp /usr/share/X11/fonts/100dpi:unscaled
 #> xset fp+ /usr/share/X11/fonts/100dpi
 #> xset fp rehash
 #> xset +fp /a/bad/fontdir

Now try:

 #> xlsfonts -fn '-adobe-helvetica-medium-r-normal--*-*-100-100-p-*-iso8859-1'
       => returns the name of a scalable bitmap font ('-*-0-0-100-100-p-0-*')
 #> xlsfonts -fn '-adobe-helvetica-medium-r-normal--*-94-100-100-p-*-iso8859-1'
      => returns a concreate instance of the font in a 13 point size
 #> xlsfonts -l -fn '-adobe-helvetica-medium-r-normal--*-94-100-100-p-*-iso8859-1'
      => reports that the pattern can't be matched
 #> xset fp rehash
 #> xlsfonts -l -fn '-adobe-helvetica-medium-r-normal--*-94-100-100-p-*-iso8859-1'
      => reports a matching concrete instance of the scalable font


I'm not sure who's problem this is:

  A) If gnome-settings-daemon handled the BadValue error sent in response to its XSetFontPath() request, things would be OK.
  B) If XSetFontPath() allowed for empty font directories to be added to the font path, things would be OK.
  C) If the X server really flushed _all_ knowledge of the scalable bitmap fonts from every cache, then it shouldn't report scalable names in response to ListFonts queries.
  D) If the xorg.conf file didn't include the scalable 100dpi and 75dpi font paths then there would be no problem.

The best solution would be for the X server to not return scalable
bitmap names for which it can't create concrete instances.  Then the
whole problem goes away.

** Affects: control-center (Ubuntu)
     Importance: Low
     Assignee: Ubuntu Desktop Bugs
         Status: Fix Released

-- 
Scalable bitmap font names reported but not usable after failed XSetFontPath() call
https://launchpad.net/bugs/52163