Bug 68126 - font path element errors
font path element errors
Product: Red Hat Public Beta
Classification: Retired
Component: XFree86 (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
: 70178 (view as bug list)
Depends On:
Blocks: 67217
  Show dependency treegraph
Reported: 2002-07-06 15:11 EDT by Tammy Fox
Modified: 2007-04-18 12:43 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-08-06 03:01:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tammy Fox 2002-07-06 15:11:08 EDT
From /var/log/messages:

Jul  6 14:57:56 goofy xfs: ignoring font path element
/usr/X11R6/lib/X11/fonts/CID (unreadable) 
Jul  6 14:57:56 goofy xfs: ignoring font path element
/usr/X11R6/lib/X11/fonts/local (unreadable) 
Jul  6 14:57:56 goofy xfs: ignoring font path element
/usr/X11R6/lib/X11/fonts/latin2/Type1 (unreadable) 
Jul  6 14:57:56 goofy xfs: ignoring font path element
/usr/share/fonts/default/TrueType (unreadable) 
Jul  6 14:57:56 goofy xfs: ignoring font path element /usr/share/AbiSuite/fonts
Comment 1 Nathan G. Grennan 2002-07-07 18:44:37 EDT

Jul  4 11:26:07 cygnusx-1 xfs: ignoring font path element
/usr/X11R6/lib/X11/fonts/CID (unreadable) 
Jul  4 11:26:07 cygnusx-1 xfs: ignoring font path element
/usr/X11R6/lib/X11/fonts/local (unreadable) 
Jul  4 11:26:07 cygnusx-1 xfs: ignoring font path element
/usr/X11R6/lib/X11/fonts/latin2/Type1 (unreadable) 
Jul  4 11:26:07 cygnusx-1 xfs: ignoring font path element
/usr/share/fonts/default/TrueType (unreadable) 
Jul  4 11:26:07 cygnusx-1 xfs: ignoring font path element
/usr/share/AbiSuite/fonts (unreadable)
Comment 2 Mike A. Harris 2002-07-09 21:19:41 EDT
There aren't any details in the bug report to know what the problem is.
Remove those paths from the xfs config to get rid of the warnings.

Any font paths listed in the xfs config, which do not contain fonts, or
a valid fonts.dir, will cause the above messages to appear.  This is not
a bug, it is a warning to the user that font paths are included that are
either misconfigured, or do not contain fonts.  It is otherwise harmless.

In particular the CID and local paths do not ship with fonts in them.  The
latin2/Type1 path used to be ulT1mo fonts which we no longer ship, and so
if these fonts were removed upon upgrade, the font paths will be empty.

We currently do not remove font paths from the configs when uninstalling
fonts, since it would create a lot of random problems with uninstalling
and reinstalling fonts, ending up moving the FPE around, and giving end
users fonts which move around the font priority stack.  So we leave the
FPE's present, so if the fonts are reinstalled, they will land in the
same location in the stack the second time.

The TrueType and abiword font paths are not part of XFree86, so I'm not
sure how to classify them.

I presume this was an upgrade from RHL 7.3 to limbo?
Comment 3 Tammy Fox 2002-07-10 01:01:16 EDT
This was from a fresh install of everything. I filed the bug because I don't
think we should add paths to the font path for fonts we don't ship anymore.
Having an error message for a fresh install makes me think something went wrong.
Comment 4 Mike A. Harris 2002-07-19 13:47:40 EDT
The XFree86.spec file does not reference the CID, local, or latin2/Type1
directories or add them to the font path.  CID and local were removed
from being added to the xfs config file prior to RHL 7.3 with:

* Wed Apr 10 2002 Mike A. Harris <mharris@redhat.com> 4.2.0-6.62
- Made specfile remove fonts.dir files generated by XFree86 build, and
  "touch" them instead so they satisfy the ghost flag.  Also for the fonts.alias
  for the TTF directory.
- Removed CID directory from list of dirs to run mkfontdir in and add to
  fontpath, because our XFree86 build is not including fonts in there anymore,
  so it should not add the dir to the fontpath, nor run mkfontdir in it.

The /usr/X11R6/lib/X11/fonts/latin2/Type1 directory was part of the
ulT1mo fonts collection which is no longer part of Red Hat Linux, and
was in the fonts-ISO8859-2 package in 7.3 originally.  This directory
does not exist in XFree86 any longer, and shouldn't exist in any packages
at all.

The latter directory is an abiword directory and is not part of X either.

Even though you've stated this is a clean install, it still looks like
it was an upgraded system to me from the stuff above.  I'm not sure
how else these files would get into the tree.  They're not part of
the XFree86 package however.  Could you do an rpm -qf of the directories
to see what package is claiming ownership?
Comment 5 Tammy Fox 2002-07-23 02:44:25 EDT
[tfox@goofy tfox]$ rpm -qf /usr/X11R6/lib/X11/fonts/CID
[tfox@goofy tfox]$ rpm -qf /usr/X11R6/lib/X11/fonts/local
[tfox@goofy tfox]$ rpm -qf /usr/X11R6/lib/X11/fonts/latin2/Type1
error: file /usr/X11R6/lib/X11/fonts/latin2/Type1: No such file or directory
[tfox@goofy tfox]$ rpm -qf /usr/share/fonts/default/TrueType
error: file /usr/share/fonts/default/TrueType: No such file or directory
[tfox@goofy tfox]$ rpm -qf /usr/share/AbiSuite/fonts
error: file /usr/share/AbiSuite/fonts: No such file or directory

Comment 6 Jay Turner 2002-07-26 09:28:55 EDT
Just like to add that I'm seeing the same thing with the Milan-re0726.nightly
tree on a freshly installed system.
Comment 7 Mike A. Harris 2002-07-26 14:28:29 EDT
I believe I found the cause of this and also why I could not reproduce it.
The default xfs config file contained these paths hard coded due to
previous requests to add them.  I've removed these from the fontpath
as of XFree86-4.2.0-57.1 in rawhide.
Comment 8 Mike McLean 2002-07-26 16:45:44 EDT
Part of this problem also shows up in upgrade.log:

Upgrading XFree86-4.2.0-56.
Can't scan directory "/usr/share/fonts/default/TrueType"
Comment 9 Jay Turner 2002-07-29 17:07:14 EDT
OK, after installing XFree86-4.2.0-57.1, I'm still getting this on xfs restart:

Jul 29 17:08:25 jkt3 xfs: ignoring font path element
/usr/share/fonts/default/TrueType (unreadable)

And that path still exists in /etc/X11/fs/config.
Comment 10 Mike A. Harris 2002-08-05 14:52:54 EDT
It is in the default xfs config file.  The reason being, is to guarantee
a certain order of that path being in the config file, so that TTF fonts
are prefered.  We set the default config file up to have a certain default
ordering a few releases ago to increase the quality of the end user font

By removing all things from the font path by default, we will end up with
the fonts that a given user sees being dependant on what order they
were installed in.

For example, if a user installs Type1 or other fonts first, and installs
TrueType fonts last, then truetype would end up last in the font path.
Fonts which don't match, will match the first alias.  If truetype is last,
then uglier fonts will always be used first instead of TTF fonts.
Comment 11 Mike A. Harris 2002-08-05 16:01:54 EDT
*** Bug 70178 has been marked as a duplicate of this bug. ***
Comment 12 Mike A. Harris 2002-08-05 16:27:57 EDT
I don't see any way of fixing this blocker other than:

1) WONTFIX - this is intentionally this way
2) removing it, and having potentially large numbers of random bug
reports of fonts not looking nice, and being unable to easily reproduce
them without a lot of effort.

I'm going to go with #2 and remove the path for now.  Hopefully the
packages that put fonts in that directory have postscripts which add
the dir back to the fontpath...  or we'll be creating a new bug of
all TTF fonts not working.

I've CC'd all font package maintainers so that they can ensure that
their font packages call chkfontpath in %post

Next X build in rawhide will have this path removed.
Comment 13 Mike A. Harris 2002-08-05 19:31:49 EDT
4.2.0-60 has the changes.
Comment 14 Florian La Roche 2002-08-06 03:01:52 EDT
What about adding an empty dir, so that no warnings are given?

Comment 15 Mike A. Harris 2002-08-06 03:51:15 EDT
An empty dir present in the fontpath, or a dir without a fonts.dir
in it in the fontpath results in:

Cannot init font path element (/usr/foo/bar/baz) removing from fontpath
Comment 16 Mike McLean 2002-08-15 16:03:22 EDT
Still seeing this in upgrade.log:

Upgrading XFree86-4.2.0-64.
Can't scan directory "/usr/share/fonts/default/TrueType"

Is this a WONTFIX issue?

Note You need to log in before you can comment on or make changes to this bug.