Open Bug 553580 Opened 14 years ago Updated 1 year ago

Non installed font used instead of fallback font

Categories

(Core :: Layout: Text and Fonts, defect)

Product:
Core
Component:
Layout: Text and Fonts
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: ralf57, Unassigned)

Details

Attachments

(6 files)

Applied values in Firefox and Opera
99.67 KB, image/jpeg
Details
Applied font family in Firefox (via FontFinder extension)
41.19 KB, image/jpeg
Details
Screenshots of incorrect firefox font rendering
439.21 KB, image/png
Details
Testcase for not displaying fallback font if the first font is missing
683 bytes, text/html
Details
Screenshot of incorrect font rendering using testcase
86.09 KB, image/png
Details
Broken elements on GitHub.com
129.98 KB, image/png
Details 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100106 Ubuntu/9.10 (karmic) Firefox/3.5.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100106 Ubuntu/9.10 (karmic) Firefox/3.5.8

I have the Body font properties set in my css using the following shorthand

font : normal 0.812em Helvetica, Arial, sans-serif;

I do NOT have the "Helvetica" font installed so it should use the "Arial" fallback font which is installed on my system.
This doesn't happen but Firefox tries to use the Helvetica font instead.

Notes:
1) this happens also when using "font-family" instead of the shortand
2) Opera behaves correctly and applis the Arial font. 

Reproducible: Always

Steps to Reproduce:
1.Set the font-family property to "Helvetica, Arial, sans-serif;"
2.Be sure to not having the Helvetica font installed 
3.Load your page
Actual Results:  
The Helvetica font is used

Expected Results:  
The Arial font should be used
Version: unspecified → 3.5 Branch
The image displays the different font applied in FF and Opera (same computer and webpage)
Component: General → Layout: Text
Product: Firefox → Core
QA Contact: general → layout.fonts-and-text
Version: 3.5 Branch → unspecified
> I do NOT have the "Helvetica" font installed

Yes, but what's your fontconfig configuration?  Aliasing Helvetica to something else is a common thing for fontconfig setups to do, so when we ask for Helvetica we get back a font...

In particular, what does running:

  fc-match "Helvetica, Arial"

return on your system?  How does that compare to |fc-match "Helvetica"| and |fc-match "Arial"|?
Ok,
running
fc-match "Helvetica, Arial"
returns
n019003l.pfb: "Nimbus Sans L" "Regular"

running
fc-match "Helvetica"
returns
n019003l.pfb: "Nimbus Sans L" "Regular"

running
fc-match "Arial"
Arial.ttf: "Arial" "Normal"

Is there something wrong with my fontconfig setup?
I have also noticed this problem. For example, go to http://www.adobe.com . The associated .css file specify used font as "Myriad Pro", Helvetica, sans-serif. I do not have the Myriad Pro font installed (nor any fontconfig aliases for it), however, Firefox (4.0.1) uses it for rendering the page (probably by falling back to fontconfig default).

Even more interestingly,  FontFinder extension reports fonts as: font-family (stack): "myriad-pro-1", "myriad-pro-2" ,"Helvetica", "Arial", sans-serif Font being rendered: "myriad-pro-1", which means that "Myriad Pro" somehow became "myriad-pro-1" and "myriad-pro-2".

OS is Slackware Linux 13.37, with default fontconfig configuration.
Update:
The styles that specify "myriad-pro-1" and "myriad-pro-2" fonts are created dinamically, by typekit.js. With JavaScript disabled, or when viewing pages without JavaScript-created css, everything works right.
I've seen this strange interaction between Firefox and fontconfig crop up numerous times as well. Currently using Arch Linux, and it happens all the time with both Firefox 4 and 5. Usually I have to add special rules to fontconfig's local.conf to get Firefox to choose something sane as an alternative to fonts I don't have, because it seems to ignore the fallback fonts specified in font-family CSS properties. It can be very irritating.
I have exactly the same problem.
I'm also using Arch 64 bit (kernel 2.6.39-ARCH) under KDE 4.7.

If the first font specified is not present, some other (usually ugly bitmap or fixed size font is used.) 

If I use CTRL + to increase the page zoom the correct behaviour usually returns. Sometimes I have to hit CTRL + twice for the effect to work.

I also have Chromium (13.0.782.107) and Konqueror (4.7.0) and they both behave correctly.
Here is a composite illustrating the problem, I don't have "Segoe UI" installed but I DO have Calibri. I do NOT have any fontconfig configuration regarding the "Segoe UI" font.

$ fc-match "Segoe UI"
DejaVuSans.ttf: "DejaVu Sans" "Book"
$ fc-match "Segoe UI,Calibri,Myriad Pro,Myriad,Trebuchet MS,Helvetica,Arial,sans-serif"
calibri.ttf: "Calibri" "Regular"

This occurs whenever the FIRST font specified in a css class ( regardless of whether it uses font: ot font-family: )

This is a pretty serious bug for me as it makes a LOT of pages look extremely ugly.
Sorry I should point out I used firebug to illustrate the bug but the same issue is present when using firefox nightly 8.0a1 (2011-08-05) with a completely new profile.
I don't know if this info helps, but the problem exists only on Linux (tried several x86 and x86_64 distributions). On various *BSD systems and Windows, everything works correctly. So, it is something Linux-specific, although I can't find what. The same X.org and fontconfig are on BSDs, and there aren't any problems.
Well after maybe a couple of months of frustration and annoyance I've finally solved my problem. 
I had a font configuration rule file in /etc/fonts/conf.d 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 though and indeed (in my opinion) fc-match is reporting the correct values. Both Chromium and Konqueror are also getting those values.
For some reason firefox isn't - it's somehow obtaining the ugly bitmap font to render for 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.
OS is Debian Jessie/sid 32bit, testing current nightly and stable builds. 

Font "Calibri" does not exist on this machine, but the second font in the "font-family" property does not get used.

"fc-match Calibri" returns "arial.ttf: "Arial" "Normal", which does not get used either as you can see in the screenshot.
I confirm that this problem remains unsolved. Everything I wrote in my comment 3 1/2 years ago is still true. It exists only in Firefox on Linux, which can be confirmed by test cases or, more easyly, by "Font Finder" add-on.
I can confirm similar problems. With "font-family: Linux Libertine", Linux Libertine is used; but with "font-family: Linux Libertine, Times", suddenly Nimbus Roman No9 L, the local replacement for Times according to fc-match, is used. This can be observed on Wikipedia’s h1, for example.

I think this bug is responsible for GitHub looking janky in Firefox in Ubuntu 20.04.

GitHub's style specifies

font-family: -apple-system,BlinkMacSystemFont,Segoe UI,Helvetica,Arial,sans-serif,Apple Color Emoji,Segoe UI Emoji

Somehow Firefox picks Nimbus Sans for this. Chromium picks Arial, which looks good.

fc-match -- -apple-system returns DejaVu Sans
fc-match BlinkMacSystemFont returns DejaVu Sans
fc-match "Segoe UI" returns DejaVu Sans
fc-match Helvetica returns Nimbus Sans
fc-match Arial returns Arial
fc-match sans-serif returns DejaVu Sans
fc-match "Apple Color Emoji" returns Noto Color Emoji
fc-match "Segoe UI Emoji" returns Noto Color Emoji

It looks like your fontconfig configuration doesn't resolve -apple-system, BlinkMacSystemFont, or "Segoe UI" to anything specific -- DejaVu Sans is just the default it'll return for any unknown name -- but it does provide Nimbus Sans as an alias/substitute for Helvetica, and so that gets used (because Helvetica is ahead of Arial in the font-family list). To prevent this you should remove the configuration file that specifies Nimbus Sans as the substitute for Helvetica.

Would it be incorrect to rename this bug to the following? Is this the central request?

Don't use fontconfig on Linux

Perhaps, but if we don't honor fontconfig rules then people complain about that, too (e.g. bug 1648085).

I'm having exactly the same display issues on a default installation of Fedora 33.

Most notably affected is GitHub.com (see https://github.com/primer/css/issues/1209).

These are my outputs of fc-match:

$ fc-match -- -apple-system
Vera.ttf: "Bitstream Vera Sans" "Regular"
$ fc-match BlinkMacSystemFont
Vera.ttf: "Bitstream Vera Sans" "Regular"
$ fc-match "Segoe UI"
Cantarell-Regular.otf: "Cantarell" "Regular"
$ fc-match Helvetica
NimbusSans-Regular.otf: "Nimbus Sans" "Regular"
$ fc-match Arial
LiberationSans-Regular.ttf: "Liberation Sans" "Regular"
$ fc-match sans-serif
Vera.ttf: "Bitstream Vera Sans" "Regular"
$ fc-match "Apple Color Emoji"
NotoColorEmoji.ttf: "Noto Color Emoji" "Regular"
$ fc-match "Segoe UI Emoji"
NotoColorEmoji.ttf: "Noto Color Emoji" "Regular"
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: