Ubuntu

Updating /var/cache/fontconfig with no-bitmaps disables bitmap fonts also for users that enable them

Reported by Martin Stjernholm on 2007-04-26
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Fontconfig
Fix Released
Medium
fontconfig (Ubuntu)
Medium
Unassigned

Bug Description

Workaround: sudo rm /var/cache/fontconfig/*

Binary package hint: fontconfig

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">
<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.

==============================================

If I have bitmaps fonts disabled (i.e. /etc/fonts/conf.d/70-no-bitmaps.conf exists) while running "sudo fc-cache -r -s -v" to update /var/cache/fontconfig, then I won't get the bitmap fonts in e.g. /usr/share/fonts/X11/misc even if I enable bitmap fonts in my personal ~/.fonts.conf file. Updating the local cache in ~/.fontconfig doesn't make any difference.

Ubuntu Feisty.

Daniel T Chen (crimsun) wrote :

Is this symptom still reproducible in 8.10 beta?

Changed in fontconfig:
status: New → Incomplete
Martin Stjernholm (msub) wrote :

It's easily tested if one uses that version, which I don't. Fwiw, I just checked in Hardy, and the problem is the same there.

Changed in fontconfig:
status: Incomplete → New
Roy Jamison (xteejx) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

Changed in fontconfig (Ubuntu):
status: New → Incomplete
Martin Stjernholm (msub) wrote :

It's better in Jaunty, but there are still some differences:

With /etc/conf.d/70-no-bitmaps.conf:

> fc-list fixed
Fixed:style=Bold
Fixed:style=Bold SemiCondensed
Fixed:style=SemiCondensed
Fixed:style=Oblique SemiCondensed
Fixed:style=Oblique
Fixed:style=Regular

Without /etc/conf.d/70-no-bitmaps.conf:

> fc-list fixed
Fixed:style=Bold
Fixed:style=Bold SemiCondensed
Fixed:style=SemiCondensed
Fixed:style=Oblique SemiCondensed
Fixed:style=Oblique
Fixed:style=ko
Fixed:style=ja
Fixed:style=Regular

In both cases I have enabled bitmap fonts locally in my ~/.fonts.conf using this:

  <selectfont>
    <acceptfont>
      <pattern>
 <patelt name="scalable"><bool>false</bool></patelt>
      </pattern>
    </acceptfont>
  </selectfont>

In any case, "sudo fc-cache -r -s -v" appears to do its job properly now.

Roy Jamison (xteejx) wrote :

Can you give us steps to reproduce this in Jaunty, so we can debug this further. Thanks :)

Roy Jamison (xteejx) wrote :

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

Changed in fontconfig (Ubuntu):
status: Incomplete → Invalid
rmark (rmark33) wrote :

I use debian lenny and I have met the same problem: the user can not use bitmap fonts using an appropriate ~/.fonts.conf file. If /var/cache/fontconfig exists it is used instead of the local one (~/.fontconfig).
I reversed two lines in file /etc/fonts/fonts.conf that define the cache path. Now the first one is the local that is followed by the system-wide cache path:
<cachedir>~/.fontconfig</cachedir>
<cachedir>/var/cache/fontconfig</cachedir>
After it user level changes has effect.

It is better to write these lines in a new file: local.conf or in your own ~/.fonts.conf since /etc/fonts/fonts.conf should not be edit by hand.

Roy Jamison (xteejx) wrote :

Marking Confirmed. This is still an issue as explained above. Is it possible for you to try this with the development release (Lucid Lynx) please? You should be able to do this with the Live CD.
Informing upstream, will add bug watch.

Changed in fontconfig (Ubuntu):
importance: Undecided → Low
status: Invalid → Confirmed
Roy Jamison (xteejx) wrote :

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

Changed in fontconfig (Ubuntu):
importance: Low → Undecided
status: Confirmed → Invalid
Martin Stjernholm (msub) wrote :

I've now tested with Maverick RC, and the problem is still the same as in Jaunty. I tried rmarks suggestion with changing the order of the <cachedir> elements in /etc/fonts/fonts.conf. It works, but only if I have no bitmap fonts overrides in my local ~/.fonts directory.

To fully fix the issue, I still have to remove /etc/fonts/conf.d/70-no-bitmaps.conf to get all the bitmap fonts I need (in particular the "fixed" font).

Changed in fontconfig (Ubuntu):
status: Invalid → New
Martin Stjernholm (msub) wrote :

I might clarify comment #4 a bit. The reason I still saw some (but not all) fixed fonts in the first fc-list there was that those were my personal overrides in ~/.fonts. If I remove those, then doing "fc-list fixed" with 70-no-bitmaps.conf is in place produces an empty list.

Roy Jamison (xteejx) wrote :

Sorry I didn't get back on this. Is the problem still the same with the final fully updated release of 10.10? Thank you.

Changed in fontconfig (Ubuntu):
status: New → Incomplete
Launchpad Janitor (janitor) wrote :

[Expired for fontconfig (Ubuntu) because there has been no activity for 60 days.]

Changed in fontconfig (Ubuntu):
status: Incomplete → Expired
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">
<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.

Changed in fontconfig (Ubuntu):
status: Expired → New
Roy Jamison (xteejx) wrote :

Thank you for all the information, it's been a great help. I have marked this Triaged and passed it on to the developers, you can track it and make comments at https://bugs.freedesktop.org/show_bug.cgi?id=36577 . This may be Ubuntu-specific, but the developers I'm sure will know whether that is the case or not. Thank you again for reporting this to us :)

Changed in fontconfig (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
description: updated
Changed in fontconfig:
importance: Unknown → Medium
status: Unknown → Confirmed
Changed in fontconfig:
status: Confirmed → Fix Released
Martin Stjernholm (msub) wrote :

I can reproduce this in Precise. Has the fix still not propagated from upstream?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.