Bug 490888 - All fonts are monospace after upgrade to fontconfig-2.6.99.behdad-3
All fonts are monospace after upgrade to fontconfig-2.6.99.behdad-3
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: fontconfig (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Behdad Esfahbod
Fedora Extras Quality Assurance
:
: 491604 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-18 09:11 EDT by Michal Schmidt
Modified: 2009-05-28 05:24 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-26 00:27:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Schmidt 2009-03-18 09:11:25 EDT
Description of problem:
Today I did 'yum update' on my Rawhide KVM guest. About 20 packages were updated, among them was fontconfig. After reboot to get the new kernel, all fonts in GDM were monospaced and without antialiasing. After logging in into GNOME everything was monospaced and no AA too (menus, window titles, gnome-terminal, ...). I thought I had lost my Preferences -> Appearance -> Fonts settings, so I went there to check, but all fonts appeared the same.

The problem was fixed it by running 'fc-cache -r' and logging out and back in.


Version-Release number of selected component (if applicable):
The upgrade was from:
fontconfig-2.6.97-5.g945d6a4.fc11.x86_64
to:
fontconfig-2.6.99.behdad-3.fc11.x86_64

How reproducible:
Not sure. I haven't tried downgrading and repeating the upgrade yet.

Steps to Reproduce:
1. Update fontconfig 
2. Reboot (although relogin would probably be sufficient)
  
Actual results:
All fonts are monospace and without antialiasing.

Expected results:
Font should look as they did before the upgrade.

Additional info:
I suspect the bug is in fontconfig's postinstall script where it does:
rm -f /var/cache/fontconfig/????????????????????????????????.cache-2
But at least on my system the number of question marks does not correspond to the actual filename lengths of the files in that directory. E.g.
/var/cache/fontconfig/3830d5c3ddfd5cd38a049b759396e72e-x86-64.cache-2

(the "-x86-64" is not accounted for)
Comment 1 Behdad Esfahbod 2009-03-18 13:41:45 EDT
The rm is there to cleanup earlier naming convention where there was no arch in the file name.  So that's not the issue.

Did the update also update any font packages?
Comment 2 Behdad Esfahbod 2009-03-18 17:07:40 EDT
Ok, I understand the bug now.  Working on a fix.
Comment 3 Behdad Esfahbod 2009-03-18 19:36:38 EDT
commit a03e7b11fbe9a4710575f27e8701fcd7fa902844
Author: Behdad Esfahbod <behdad@behdad.org>
Date:   Wed Mar 18 19:28:52 2009 -0400

    [fc-lang] Make LangSet representation in the cache files stable
    
    Fontconfig assigns an index number to each language it knows about.
    The index is used to index a bit in FcLangSet language map.  The bit
    map is stored in the cache.
    
    Previously fc-lang simply sorted the list of languages and assigned
    them an index starting from zero.  Net effect is that whenever new
    orth files were added, all the FcLangSet info in the cache files would
    become invalid.  This was causing weird bugs like this one:
    
      https://bugzilla.redhat.com/show_bug.cgi?id=490888
    
    With this commit we fix the index assigned to each language.  The index
    will be based on the order the orth files are passed to fc-lang.  As a
    result all orth files are explicitly listed in Makefile.am now, and
    new additions should be made to the end of the list.  The list is made
    to reflect the sorted list of orthographies from 2.6.0 released followed
    by new additions since.
    
    This fixes the stability problem.  Needless to say, recreating caches
    is necessary before any new orthography is recognized in existing fonts,
    but at least the existing caches are still valid and don't cause bugs
    like the above.
Comment 4 Behdad Esfahbod 2009-03-18 19:54:58 EDT
Built fontconfig-2.6.99.behdad.20090318-1.fc11
Requesting tag now.
Comment 5 Behdad Esfahbod 2009-03-18 20:01:46 EDT
https://fedorahosted.org/rel-eng/ticket/1401
Comment 6 Deji Akingunola 2009-03-18 20:27:18 EDT
(In reply to comment #4)
> Built fontconfig-2.6.99.behdad.20090318-1.fc11

WORKSFORME (had similar issue reported with 2.6.99.behdad-3.fc11.x86_64).
Comment 7 Behdad Esfahbod 2009-03-18 21:12:51 EDT
(In reply to comment #6)
> (In reply to comment #4)
> > Built fontconfig-2.6.99.behdad.20090318-1.fc11
> 
> WORKSFORME (had similar issue reported with 2.6.99.behdad-3.fc11.x86_64).  

Cool.  So you had broken fonts, updated, and they were not broken anymore?
Comment 8 Deji Akingunola 2009-03-18 22:28:21 EDT
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #4)
> > > Built fontconfig-2.6.99.behdad.20090318-1.fc11
> > 
> > WORKSFORME (had similar issue reported with 2.6.99.behdad-3.fc11.x86_64).  
> 
> Cool.  So you had broken fonts, updated, and they were not broken anymore?  

Something close to that. I have other fonts (not included in Fedora anymore) installed and my font preferences set in /etc/fonts/local.conf. But on update to fontconfig-2.6.99.behdad-3.fc11.x86_64, the custom settings doesn't have any effects, and my monospaced fonts revert to stock Fedora's.
Comment 9 A S Alam 2009-05-28 05:24:43 EDT
*** Bug 491604 has been marked as a duplicate of this bug. ***

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