Bug 36577 - Updating /var/cache/fontconfig with no-bitmaps disables bitmap fonts also for users that enable them
Summary: Updating /var/cache/fontconfig with no-bitmaps disables bitmap fonts also for...
Status: RESOLVED FIXED
Alias: None
Product: fontconfig
Classification: Unclassified
Component: fc-cache (show other bugs)
Version: 2.8
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Keith Packard
QA Contact: Behdad Esfahbod
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-25 04:00 UTC by Roy Jamison
Modified: 2011-06-20 08:10 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Roy Jamison 2011-04-25 04:00:27 UTC
This bug was originally filed at Launchpad at https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/110358

Preconditions: /etc/fonts/conf.d/70-no-bitmaps.conf is present and the fontconfig cache has been populated with "fc-cache -s".

1. Create a user-specific ~/.fonts.conf containing the following to enable bitmap fonts for the current user:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
  <selectfont>
    <acceptfont>
      <pattern>
 <patelt name="scalable"><bool>false</bool></patelt>
      </pattern>
    </acceptfont>
  </selectfont>
</fontconfig>

2. Optionally do "fc-cache -f" (the following results are the same both with and without this step).

3. Try "fc-list fixed". Expected: A number of entries, including "Fixed:style=Regular". Observed: No output. (A more real-world severe effect is that gnome-terminal does not use the fixed font even though configured for it.)

4. sudo rm /etc/fonts/conf.d/70-no-bitmaps.conf
5. sudo fc-cache -f -s (note that -f is necessary)
6. Now "fc-list fixed" returns a number of entries, as expected.
7. sudo ln -s /etc/fonts/conf.avail/70-no-bitmaps.conf /etc/fonts/conf.d/
8. "fc-list fixed" still returns a number of entries, as expected due to ~/.fonts.conf.
9. rm ~/.fonts.conf
10. "fc-list fixed" returns nothing, as expected. This shows that the system setting takes effect properly in lack of a user local override.

The bug is present already in step 3. I believe the remaining steps suggest that the problem is that "fc-cache -s" takes <rejectfont> rules into account when populating the global cache, which is incorrect since the fonts thus left out won't be available when a user local <acceptfont> takes precedence. Also, refreshing the user-local cache through "fc-cache -f" has no effect.

Side note: This is a quite old bug by now. I've grown used to do sudo rm /etc/fonts/conf.d/70-no-bitmaps.conf after every upgrade, so it's only a mild annoyance to me personally. The full scope of the problem is probably larger though.
Comment 1 Behdad Esfahbod 2011-04-26 21:10:07 UTC
The acceptfont/rejectfont are not supposed to affect the cache.  So something is clearly not working as expected.
Comment 2 Akira TAGOH 2011-06-20 05:03:08 UTC
Okay, I've tracked this down finally, on Ubuntu 11.04. apparently 70-no-bitmaps.conf affects fc-cache to generate caches. Since fontconfig relies on the cache unless the timestamp on directory and fonts is newer than the cache? fontconfig considered no fonts there.
Thus, fc-list doesn't output anything regardless of what any config in .fonts.conf. actually if you copy it into /root and run fc-cache as root or simply run "fc-list fixed" as root in some cases, cache files are updated and even $HOME/.fonts.conf for users takes effects.

As per comment#1, affecting acceptfont and rejectfont to the cache is a bug here.
it should be simply ignored for cache generations.

As I described above, run fc-cache as root without no-bitmaps.conf would be a workaround.
Comment 4 Akira TAGOH 2011-06-20 05:30:54 UTC
You need to run fc-cache -f again to correct the cache files, of course.
Comment 5 Behdad Esfahbod 2011-06-20 08:03:38 UTC
Does the font blacklisting still work with your patch?
Comment 6 Behdad Esfahbod 2011-06-20 08:08:06 UTC
Right.  I see that it should still work.  Committing slightly modified patch.
Comment 7 Behdad Esfahbod 2011-06-20 08:10:02 UTC
Pushed to master.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.