Comment 14 for bug 110358

Martin Stjernholm (msub) wrote :

This bug still exists in Natty beta 2. To reiterate, here are exact steps and expected vs observed behavior:

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">
 <patelt name="scalable"><bool>false</bool></patelt>

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.