I'm not at all sure if this is a bug or not, but it sure looks like one to me. My issue is about how the user configuration files '/etc/fonts/local.conf' and '~/.fonts.conf' get handled. Users are supposed to enter their settings in either '/etc/fonts/local.conf' or '~/.fonts.conf' and are not supposed to touch '/etc/fonts/fonts.conf' at all. This seems like a good idea assuming that user configuration files take precedence over the default configuration file. So, any change I make on '/etc/fonts/local.conf' should take precedence over /etc/fonts/fonts.conf'. And any change to '~/.fonts.conf' should take precedence over the other two. Files '/etc/fonts/local.conf' '~/.fonts.conf' get included inside '/etc/fonts/fonts.conf' somewhere in the middle of the file. This means that any settings defined after the inclusion will override our user defined settings. Instead, the inclusion should happen at the end of '/etc/fonts/fonts.conf'. I recently run into this issue with a font that doesn't have a bold face defined. Inside '/etc/fonts/fonts.conf' there's a section to force synthetic emboldening of such fonts. In my particular case this synthetic emboldening produced a huge ugly bold font. I tried to disable the synthetic emboldening for this font by editing '/etc/fonts/local.conf' with no luck. The problem was that inside of '/etc/fonts/fonts.conf' the synthetic emboldening was defined after the inclusion of the user configuration files. So any settings I defined about emboldening were overruled by the default configuration. Applying this patch to '/etc/fonts/fonts.conf' solved the issue for me: $ diff -u fonts.conf fonts.conf.fix --- fonts.conf 2006-09-04 16:17:30.000000000 -0600 +++ fonts.conf.fix 2006-09-04 16:19:29.000000000 -0600 @@ -241,16 +241,6 @@ </edit> </match> -<!-- - Load per-user customization file ---> - <include ignore_missing="yes">~/.fonts.conf</include> - -<!-- - Load local system customization file ---> - <include ignore_missing="yes">conf.d</include> - <include ignore_missing="yes">local.conf</include> <!-- Provide required aliases for standard names @@ -446,4 +436,17 @@ </rescan> </config> + +<!-- + Load local system customization file +--> + <include ignore_missing="yes">conf.d</include> + <include ignore_missing="yes">local.conf</include> + +<!-- + Load per-user customization file +--> + <include ignore_missing="yes">~/.fonts.conf</include> + + </fontconfig>
I submitted this bug to the freedesktop.org bugzilla and got a reply that fixed my problem. The bug is: https://bugs.freedesktop.org/show_bug.cgi?id=8219 The suggested fix worked fine in my machine. The fix is to enter this in your /etc/fonts/local.conf file: <match target="font"> <test name="family"> <string>fontname</string> </test> <!-- check to see if the font is just regular --> <test name="weight" compare="less_eq"> <const>medium</const> </test> <!-- check to see if the pattern requests bold --> <test target="pattern" name="weight" compare="more"> <const>medium</const> </test> <!-- set weight to bold needed for applications using Xft directly, e.g. Firefox, ... --> <edit name="weight" mode="assign"> <const>bold</const> </edit> </match> Where 'fontname' is the family name of the font.
