Reproduced

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)

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?

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.

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> 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?

[tfox@goofy tfox]$ rpm -qf /usr/X11R6/lib/X11/fonts/CID
XFree86-base-fonts-4.2.0-52
[tfox@goofy tfox]$ rpm -qf /usr/X11R6/lib/X11/fonts/local
XFree86-base-fonts-4.2.0-52
[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

Just like to add that I'm seeing the same thing with the Milan-re0726.nightly
tree on a freshly installed system.

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.

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"

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.

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
experience.

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.

*** Bug 70178 has been marked as a duplicate of this bug. ***

I don't see any way of fixing this blocker other than:

1) WONTFIX - this is intentionally this way
or
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.

4.2.0-60 has the changes.

What about adding an empty dir, so that no warnings are given?

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

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?