[Bug 1169979] New: Some fonts not in fontconfig cache on Fedora 21 live images

bugzilla at redhat.com bugzilla at redhat.com
Tue Dec 2 21:57:48 UTC 2014


            Bug ID: 1169979
           Summary: Some fonts not in fontconfig cache on Fedora 21 live
           Product: Fedora
           Version: 21
         Component: fontconfig
          Assignee: tagoh at redhat.com
          Reporter: awilliam at redhat.com
        QA Contact: extras-qa at fedoraproject.org
                CC: fonts-bugs at lists.fedoraproject.org,
                    i18n-bugs at lists.fedoraproject.org, pnemade at redhat.com,
                    tagoh at redhat.com

We've spotted an issue with Fedora 21 live images where some installed fonts
appear to be missing from the fontconfig cache in the live environment. An
'fc-cache -f' fixes this. For instance, on the Fedora 21 Final RC2 Workstation
x86_64 live:

[root at localhost liveuser]# fc-list | wc -l
[root at localhost liveuser]# fc-cache --force
[root at localhost liveuser]# fc-list | wc -l

The specific fonts that are missing on that image are:

/usr/share/fonts/dejavu/DejaVuSansMono-BoldOblique.ttf: DejaVu Sans
Mono:style=Bold Oblique
/usr/share/fonts/dejavu/DejaVuSansMono-Bold.ttf: DejaVu Sans Mono:style=Bold
/usr/share/fonts/dejavu/DejaVuSansMono-Oblique.ttf: DejaVu Sans
/usr/share/fonts/dejavu/DejaVuSansMono.ttf: DejaVu Sans Mono:style=Book

/usr/share/fonts/dejavu/DejaVuSerif-BoldItalic.ttf: DejaVu Serif:style=Bold
/usr/share/fonts/dejavu/DejaVuSerif-Bold.ttf: DejaVu Serif:style=Bold
/usr/share/fonts/dejavu/DejaVuSerifCondensed-BoldItalic.ttf: DejaVu
Serif,DejaVu Serif Condensed:style=Condensed Bold Italic,Bold Italic

/usr/share/fonts/dejavu/DejaVuSerifCondensed.ttf: DejaVu Serif,DejaVu Serif
/usr/share/fonts/dejavu/DejaVuSerif-Italic.ttf: DejaVu Serif:style=Italic
/usr/share/fonts/dejavu/DejaVuSerif.ttf: DejaVu Serif:style=Book

/usr/share/fonts/google-noto/NotoSansTagalog-Regular.ttf: Noto Sans
/usr/share/fonts/google-noto/NotoSansTaiViet-Regular.ttf: Noto Sans Tai

/usr/share/fonts/liberation/LiberationSerif-BoldItalic.ttf: Liberation
Serif:style=Bold Italic
/usr/share/fonts/liberation/LiberationSerif-Bold.ttf: Liberation
/usr/share/fonts/liberation/LiberationSerif-Italic.ttf: Liberation
/usr/share/fonts/liberation/LiberationSerif-Regular.ttf: Liberation

The log of the compose is here:


In comparison, the i686 Workstation live is 'missing' only

/usr/share/fonts/google-noto/NotoSansTaiViet-Regular.ttf: Noto Sans Tai

its compose log is here:


to me, it appears the affected cases are ones where more than one package
contains fonts in the same directory, for packages installed *after* the
fontconfig package. The fontconfig package has an 'fc-cache -f' in its %post,
so any inconsistencies that exist before it's installed get fixed by that.

My first thesis was 'for any given directory, only fonts from the first package
installed after fontconfig will make it to the cache, fonts in the same
directory from subsequently-installed packages won't be added'. But it doesn't
seem to be that simple, because some fonts in /usr/share/fonts/google-noto
*are* added - the first 'noto' package installed is google-noto-sans-lisu-fonts
, and after that several more noto packages are installed. The fonts from
google-noto-sans-mandaic-fonts, google-noto-sans-meeteimayek-fonts , and
google-noto-sans-tai-tham-fonts *do* get added to the cache - but the fonts
from google-noto-sans-tagalog-fonts and google-noto-sans-tai-viet-fonts do
*not* get added. It's quite odd.

This is a fairly bad bug because of its impact on DejaVu Sans Mono: this is the
default monospace font for both Workstation and KDE (and I think the
non-blocking spins too). Its absence from the cache results in them using
Nimbus Mono L as their monospace fonts, which is a pretty crappy font, ugly and
hard to read. The workaround is easy once you know it, but if you don't, you
just think we have a really bad font.

There's an easy big hammer workaround we can use for a quick rebuild of the RC2
lives, if we like:

--- a/fedora-live-base.ks
+++ b/fedora-live-base.ks
@@ -299,6 +299,12 @@ rm -f /core*
 # convince readahead not to collect
 # FIXME: for systemd

+# forcibly regenerate fontconfig cache (so long as this live image has
+# fontconfig) - see #XXXXXXX
+if [ -x /usr/bin/fc-cache ] ; then
+   fc-cache -f

i.e., just do an fc-cache -f at the end of live generation %post. I've tested
that locally, and it works, the generated Workstation image has 159 fonts in
fc-list (I also generated an image with the exact same config and build host,
but no change to spin-kickstarts, to verify that it reproduced the bug, and it

The real fix should likely be in fc-cache, but the spin-kickstarts workaround
would solve this problem for F21.

I think fc-cache's behaviour must have changed between F20 and F21, as F20
doesn't appear to be affected by this at all, at least not the x86_64 desktop
live. All F21 images I've tested seem to be affected to some extent, though the
exact affected fonts vary depending on the package install order that yum
decided on.

You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=YTmueYxE1e&a=cc_unsubscribe

More information about the fonts-bugs mailing list