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:
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
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.
The acceptfont/rejectfont are not supposed to affect the cache. So something is clearly not working as expected.
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.
proposed patch for this:
You need to run fc-cache -f again to correct the cache files, of course.
Does the font blacklisting still work with your patch?
Right. I see that it should still work. Committing slightly modified patch.
Pushed to master.