You are not logged in.
Perhaps I'm just misunderstanding something, but it seems like Firefox doesn't handle font fallback the way that I would consider to be correct.
Instead of respecting the font-family list defined in CSS, it appears to just take the first font from that list and use whatever fontconfig returns as the best match. In most cases, this is fine, but sometimes the first font listed in the CSS is one that I don't have, and in that case fontconfig returns something bogus, completely unlike the requested font. I understand why it does this, but in the specific case of rendering web pages, it would be preferable for the browser to just try the next font in the CSS list instead of blindly going with fontconfig's "best match".
Chromium seems to do the "right thing" in this case, so I know that it must be possible for Firefox as well. But it seems that no matter what I try, Firefox simply refuses to use anything other than the first font listed in the font-family list. This kind of defeats the whole purpose of having that list, doesn't it? Web designers shouldn't have to worry about specifying obscure fonts in CSS as long as they provide sane fallbacks.
I know about adding alias rules in fontconfig's config files so that fonts that I don't have will render using some other, similar font. But my /etc/fonts/local.conf is getting very large with all of my special case rules, and yet I still run into webpages, on nearly a daily basis, where the fonts are clearly wrong. If Firefox would just respect the way that CSS is supposed to work in this case, this wouldn't be necessary.
Am I the only one that sees this problem? Is there some configuration setting that I'm just stupidly overlooking here? Or am I stuck forever adding zillions of special rules to fontconfig for all the obscure fonts that web designers decide to use?
Last edited by tmhedberg (2011-07-31 07:08:59)
Offline
Am I the only one that sees this problem?
Pretty much. The people who care, tend to care that the font that is actually used *looks* good, rather than caring quite so much as you as to *which* font is used.
Please provide some examples of bad web pages, and the fontconfig tweaks you're using.
Offline
Please provide some examples of bad web pages, and the fontconfig tweaks you're using.
Actually, I think I explained the problem poorly, and I omitted some relevant information from the original post.
To illustrate:
$ fc-match 'DejaVu Sans'
DejaVuSans.ttf: "DejaVu Sans" "Book"
$ fc-match Century
DejaVuSans.ttf: "DejaVu Sans" "Book"
I don't have a font called "Century" installed, so fontconfig just falls back to its default, which happens to be DejaVu Sans. That's fine in the general case.
Here's a webpage with `font-family: Century, serif` in its CSS: http://goertzel.org/dynapsyc/yamaguchi.htm. So if Century is not available, Firefox should fall back to the default "serif" font set in the Firefox preferenes, which in my case is Times New Roman.
Instead, I get this ugliness: http://tmh.cc/img/ff_ugly.png
If I use Firebug to change the first font in the CSS font-family list to "DejaVu Sans", it looks good: http://tmh.cc/img/ff_dejavu.png. Or, if I just remove Century from the list entirely, so that it just says "serif", the I get Times New Roman, as expected: http://tmh.cc/img/ff_times.png.
So it seems that Firefox is consulting fontconfig for the first font in the CSS list, as I said before. But when fontconfig just returns its default font (or more likely, if the fontconfig value is too far off from what Firefox wants), then it's not using fontconfig's font, nor is it falling back to the second font in the CSS list. It just uses something completely different, and quite ugly.
My custom rules in /etc/fonts/local.conf are just a bunch of these:
<!-- Replace Times with Times New Roman -->
<match target="pattern" name="family">
<test name="family" qual="any">
<string>Times</string>
</test>
<edit name="family" mode="assign">
<string>Times New Roman</string>
</edit>
</match>
Each of which maps a font name that fontconfig doesn't match properly to a font that I actually have. But having to add so many of these rules specifically for Firefox when other applications, even other web browsers, seem to have no problem is very irritating and seems unneccesary. I suspect that I'm missing something obvious, hence this thread.
Offline
People simply install *.ttf from an old Windows CD, or dual-booted Windows installation, or something similar. So they *have* the fonts installed, so the web pages are rendered as their authors intended.
If your installed fonts look ugly, then gain the knowledge to fix that, by reading the huge Gentoo fonts thread. Disable bitmap fonts, and install a decent freetype patchset. All stuff I've said a million times before.
Offline
You're missing the point.
This isn't a question about missing fonts. Obviously, if I don't have a particular font installed, then Firefox won't be able to render text with that font. It's not always feasible to get a copy of every font that I'm missing, but that's completely beside the point. I am not asking what to do about missing fonts.
The point is that I don't understand Firefox's behavior regarding font fallback in the absence of a particular font. Web standards dictate that it should use the font-family list defined in CSS to determine which font to use for rendering a particular body of text. In the example I gave, since Century was not available, it should have fallen back to Times. But Firefox doesn't do this. Nor does it even accept fontconfig's inferior suggestion of DejaVu. It does its own thing completely, chooses an ugly font, and I have no idea what the font is or where it's coming from. It's not from fontconfig or the CSS. All I'm asking is, is this configurable behavior, or is it just the way that Firefox works?
So they *have* the fonts installed, so the web pages are rendered as their authors intended.
The CSS font-family list is what the author intended. That's what it's there for. And Firefox does not respect it.
I know how to configure fontconfig. I have Freetype patches installed. I've read the Gentoo thread. I won't disable bitmap fonts, because I actually use them in other contexts. None of this has anything to do with my question, which is not about font rendering. It is about the seeming flawed algorithm that Firefox employs to select alternative fonts when the first choice is not present on the system.
Offline
Nor does it even accept fontconfig's inferior suggestion of DejaVu
That statement should have been in your opening comment - we are not mind-readers.
What does this command show for you?
$ fc-match serif
times.ttf: "Times New Roman" "Normal"
Use something like this to identify the font file:
lsof | grep -i firefox | egrep -i 'ttf|pfb'
Although if it's a bitmap font, it won't have one of those file extensions.
As to the firefox algorithm, I dunno - never been a concern.
Offline
That statement should have been in your opening comment - we are not mind-readers.
Indeed it should have. But that's precisely what I was trying to illustrate with the example in my second post. If it wasn't clear from that, then mea culpa, I guess.
What does this command show for you?
$ fc-match serif
DejaVuSerif.ttf: "DejaVu Serif" "Book"
This corresponds to /usr/share/fonts/TTF/DejaVuSerif.ttf on my system. But it isn't the font that Firefox is actually using. If I create a test HTML page that explicitly uses "DejaVu Serif", it looks just fine, and renders properly. But when fontconfig suggests that font as an alternative to some other, unavailable font, Firefox uses something else entirely, not what fontconfig is suggesting, nor any of the fonts listed in the CSS, and quite ugly.
As to the firefox algorithm, I dunno - never been a concern.
It's not really that big a deal. It's just been a minor annoyance for me for quite some time, and I figured that maybe someone here would know something about it.
Offline
Maybe this bug is of interest. I'd recommend going upstream to Mozilla anyway.
Offline
Yes, that bug does look relevant. I'd searched Mozilla's bug tracker previously but hadn't found that particular issue. Thanks.
Offline
Dear tmhedberg,
I have exactly the same problem as you
Linux 2.6.39-ARCH #1 SMP PREEMPT Sat Jul 9 14:57:41 CEST 2011 x86_64 Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz GenuineIntel GNU/Linux
I'm using KDE 4.7.
Both Chromium and Konqueror both behave in the way I expect i.e. if the first font specified in the font-family are not present they try to display the next and so on. Currently Helvetica Neue is the bane of my browsing existence as many designers are using it as their first choice font.
I understand I can configure fonconfig to deal with that specific font but I don't think I can configure it for every single font in existence that I don't have.
It hasn't always been this way though. I can't be certain but I think it is since FF 4.0 or maybe FF 5.0.
I consider this to be a bug in Firefox.
As a tip if I zoom the page (CTRL +) the correct behaviour returns.
Last edited by bhrgunatha (2011-08-04 04:31:22)
Offline
Yeah, it was definitely happening with Firefox 4 as well. Not sure about 3.6, as I was mainly using Chromium then, but I think I remember seeing it there too.
Thanks for the tip about zooming, I'll try that out next time I run into this problem.
Offline
Currently Helvetica Neue is the bane of my browsing existence as many designers are using it as their first choice font.
Mine too. That's how Google brought me here. Doing Ctrl-+ does not help... though bigger, the font still appears just as jagged. But Infinality's rendering, that brebs has linked to, worked well for me.
Thanks, brebs!
Last edited by prash (2011-08-21 22:17:17)
Offline
prash - I think you have a different issue - but I'm glad brebs' solution is working for you - it didn't help me. However - I have found a workaround:
I found a font configuration rule file in /etc/fonts/conf.d - numbered 85-... that substitutes a Chinese bitmap font (even under en-us!) for font sizes between 11px and 18px. This is over-ridden by a higher priority config rule banning bitmap fonts though! Indeed (in my opinion) fc-match is reporting the correct values. Both Chromium and Konqueror are also getting the correct values.
For some reason firefox isn't - it's somehow obtaining the ugly bitmap font to render for non those font's in that size range that aren't installed - which is why my trick of CTRL + works - it forces the font to be rendered in the larger size falling outside the range of the low priority substitution rule.
I still consider this a bug in firefox though for 2 reasons:
1) It only occurs for fonts not installed - in which case firefoz should fall back to the next fint family specified in the css file.
2) fc-match is returning a non-bitmap font anyway (in my case Arial)
However I have a workaround now - I just removed the bitmap substitution rule for the Chinese font - hey presto - things are working correctly now. I hope this can help others.
Offline