After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 752533 - Epiphany uses different fonts matching from other browsers and ignores web (CSS) fonts
Epiphany uses different fonts matching from other browsers and ignores web (C...
Status: RESOLVED NOTGNOME
Product: epiphany
Classification: Core
Component: Backend
3.16.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-07-17 14:57 UTC by Jean-François Fortin Tam
Modified: 2015-08-01 17:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
rendering in Firefox (170.03 KB, image/png)
2015-07-17 15:13 UTC, Jean-François Fortin Tam
Details
rendering in Epiphany (165.49 KB, image/png)
2015-07-17 15:14 UTC, Jean-François Fortin Tam
Details
Side by side screenshot showing Epiphany and Firefox rendering (511.91 KB, image/png)
2015-07-17 16:40 UTC, Elad Alfassa
Details

Description Jean-François Fortin Tam 2015-07-17 14:57:53 UTC
A good benchmark is http://affaires.lapresse.ca

- It uses "Verlag" as a web font (through CSS) for some of its headers
  (such as "AFFAIRES", in black, below "Accueil > Affaires").

- The rest of the website generally uses, if I'm not mistaken:
  font-family: Arial,Helvetica,sans-serif;

Compared to Firefox and other browsers (such as Konqueror), Epiphany renders it with completely different fonts, which makes the layout look clumsy.

Firefox renders the Verlag web font, and matches "Arial" to "Liberation Sans" (at least that's what the web developer toolbar tells me), which is the metrically-equivalent Free font replacement, and thus renders with the correct design intent.

As for Epiphany, it tries to uses "GNOME's default sans-serif font preference" but there isn't even such a setting available in GNOME Control Center nor GNOME Tweak Tool - and anyway, Epiphany should respect what is in the stylesheet of the webpage and try to fc-match "Arial" first (because I did not touch the default settings, and did not enable the "use-own-fonts" settings, so as I user I clearly don't want to override the website's stylesheet).

For what it's worth, on my system:

$ fc-match "Arial"
LiberationSans-Regular.ttf: "Liberation Sans" "Regular"
$ fc-match "Helvetica"
n019003l.pfb: "Nimbus Sans L" "Regular"
$ fc-match "sans-serif"
DejaVuSans.ttf: "DejaVu Sans" "Book"
$ fc-match "Sans"
DejaVuSans.ttf: "DejaVu Sans" "Book"
Comment 1 Jean-François Fortin Tam 2015-07-17 15:06:55 UTC
http://theverge.com is also a good (more obvious) benchmark for web fonts.
Comment 2 Jean-François Fortin Tam 2015-07-17 15:13:41 UTC
Created attachment 307624 [details]
rendering in Firefox
Comment 3 Jean-François Fortin Tam 2015-07-17 15:14:00 UTC
Created attachment 307625 [details]
rendering in Epiphany
Comment 4 Michael Catanzaro 2015-07-17 15:46:57 UTC
You could file a bug report against the freetype backend of WebKit, but tbh unless you have a font expert I would not expect to get anywhere on this. We intentionally do not fc-match Arial because that's prohibited by the CSS spec; we have to allow the stylesheet to control fallback, so any font specified after Arial in the stylesheet takes precedence. I think Firefox maybe has a hardcoded rule to force a match for Arial, so they get a different result. It's debatable whether we should follow the spec or not. Without font experts involved in the discussion, change is unlikely, because the code is very difficult to understand.
Comment 5 Michael Catanzaro 2015-07-17 15:51:01 UTC
I guess my summary is that "different from Firefox" is not good enough for a font bug report, we would need to see a strong argument that Firefox's behavior is correct, and what specifically is wrong in WebKit. Because TBH, we do not understand fonts either, at least I don't. :(

P.S. "Ignores web fonts" is a bit much; we definitely support woff fonts and display them on many sites. But we autohint them instead of allowing them to hint themselves, so they will usually look different than in Firefox. That usually means they'll look better in Firefox, but this is intentional, partially because letting the fonts hint themselves exposes code that is notorious for security vulnerabilities, partially because some fonts look horrendous unless we autohint.
Comment 6 Jean-François Fortin Tam 2015-07-17 16:18:17 UTC
> We intentionally do not fc-match Arial because that's prohibited by the
> CSS spec; we have to allow the stylesheet to control fallback,
> so any font specified after Arial in the stylesheet takes precedence.

Then that would explain... it seems that you have parsed the spec backwards :)
At least from what I can tell looking at various pieces of documentation:


https://developer.mozilla.org/en-US/docs/Web/CSS/font-family
> The font-family property specifies a list of fonts,
> from highest priority to lowest. 

http://www.w3schools.com/cssref/pr_font_font-family.asp  concurs.

And  http://www.w3.org/TR/css3-fonts/#font-matching-algorithm
Has a notion of "first available font":
> [...] is defined to be the first available font that would match any
> character given font families in the ‘font-family’ list 
> (or a user agent's default font if none are available). 




> "Ignores web fonts" is a bit much

Oh? That was genuinely my impression especially when looking at The Verge, the fonts are *incredibly* different, I thought it was swapping things out for "DejaVu Serif" or something like that. Are you really sure it handles them if the font is not installed on the user's system? I think I saw no problem when the web font in question was also present on the user's system.
Comment 7 Elad Alfassa 2015-07-17 16:40:34 UTC
Created attachment 307628 [details]
Side by side screenshot showing Epiphany and Firefox rendering

I agree with Jeff, Epiphany's rendering is way off here. When a web designer specifies a font on a web page, they expect a font with similar properties to be presented to the user.

However, Epiphany does not "completely ignore" web fonts. If you load the web fonts using a URL (either manually building the @font-face definition, or using Google Web Fonts), Epiphany renders the fonts correctly.
The problem is it has become a common practice to embed web fonts in CSS files as base64 data URIs, to reduce the number of HTTP requests. The Verge uses this method, which Epiphany does not seem to support.
Comment 8 Michael Catanzaro 2015-07-17 17:23:40 UTC
To be clear, Epiphany itself has nothing to do with fonts except it will set the default fonts that WebKit maps to sans, serif, fantasy, etc (by default, to the GTK+ defaults). It has nothing to do with rendering the fonts on the pages; any changes here have to be made in WebKit, specifically the freetype backend, so the place to report the bug is bugzilla.webkit.org. I say this to explain the NOTGNOME resolution; I'm trying to encourage bug reporters to use WebKit Bugzilla, which is where the issue would need to be fixed anyway.

(In reply to Jean-François Fortin Tam from comment #6)
> Then that would explain... it seems that you have parsed the spec backwards
> :)
> At least from what I can tell looking at various pieces of documentation:
> 
> 
> https://developer.mozilla.org/en-US/docs/Web/CSS/font-family
> > The font-family property specifies a list of fonts,
> > from highest priority to lowest. 
> 
> http://www.w3schools.com/cssref/pr_font_font-family.asp  concurs.
> 
> And  http://www.w3.org/TR/css3-fonts/#font-matching-algorithm
> Has a notion of "first available font":
> > [...] is defined to be the first available font that would match any
> > character given font families in the ‘font-family’ list 
> > (or a user agent's default font if none are available). 

Let's say Arial is listed first. I guess Firefox sees that and says "replace Arial with Liberation Sans, display Liberation Sans to user." That is not what we do, because it defeats the point of CSS font fallback, which is to allow the CSS to control the fallback. If you perform fontconfig matching on the first font, the web page has no way to control the font fallback: fontconfig will _always_ find a match for any font you give it, that's its job. (Hence you can be sure Firefox does not match Arial to Liberation Sans using fontconfig, but probably a hardcoded value, unless Arial is really the only font specified by the page.) So WebKit exhausts the entire list of fonts specified by the CSS before it uses fontconfig to find a different font. This can lead to different results in different browsers. Look at slashdot; their headers display sans in Firefox but serif in Epiphany. It's because they list Arial as the first font in their list, but then serif as the next font. WebKit sees you don't have Arial, so it falls back to the next font specified by the web site, and you get serif: exactly the right thing to do. (I mention this only because it's one I debugged before.)

Now, you could argue that WebKit should hardcode a few particular fallbacks, like Arial -> Liberation Sans, which I'm sure is what Chrome does and I suspect is what Firefox does here; that would be less correct, but workarounds like that are commonplace in browsers, so I wouldn't be opposed.

There are other reasons fonts can look different too. I once got a bug report about bad fonts on a site compared to Firefox that turned out to be Firefox mixed content blocking stopping a web font from being displayed and using a good-looking system font instead, while WebKit used the web font (in 2.10 WebKit will also block mixed content fonts). Hopefully this helps explain why it's not sustainable to consider "Firefox displays better fonts" bug reports; we get so many of these bug reports but never any evidence that WebKit is doing anything wrong, so we really need a very specific technical point to be brought up, or there's nothing for us to change.

> > "Ignores web fonts" is a bit much
> 
> Oh? That was genuinely my impression especially when looking at The Verge,
> the fonts are *incredibly* different, I thought it was swapping things out
> for "DejaVu Serif" or something like that. Are you really sure it handles
> them if the font is not installed on the user's system? I think I saw no
> problem when the web font in question was also present on the user's system.

Yes, on the Verge the fonts are definitely different, but see e.g. https://www.google.com/fonts <-- those are web fonts, they're not ignored. I spent a long time trying to fix a bug with poor display of web fonts before, so I would know. Compare https://www.rachelandrew.co.uk/archives/2015/07/17/css-grid-layout-at-css-day/ in Firefox and Epiphany; that's the same woff (web) font, but the hinting is broken in freetype for some reason. Epiphany autohints it, which is why it looks much better (and also why other web fonts look worse). cnn.com used to have this problem too, as have various other sites, so I decided web fonts would not be allowed to hint themselves. Chrome already does that (though they are thinking to switch to Firefox's behavior; it's really arguable what the right thing to do is). Anyway, that is a tangent, but I mention it to show that I am certain we support web fonts. :)

(In reply to Elad Alfassa from comment #7)
> I agree with Jeff, Epiphany's rendering is way off here. When a web designer
> specifies a font on a web page, they expect a font with similar properties
> to be presented to the user.

TBH, this screenshot looks exactly like the difference between autohinting and native hinting....

> However, Epiphany does not "completely ignore" web fonts. If you load the
> web fonts using a URL (either manually building the @font-face definition,
> or using Google Web Fonts), Epiphany renders the fonts correctly.
> The problem is it has become a common practice to embed web fonts in CSS
> files as base64 data URIs, to reduce the number of HTTP requests. The Verge
> uses this method, which Epiphany does not seem to support.

OK, good find. Now we have material for a bug report on bugzilla.webkit.org, if you would be willing to take the time to do that. Prefix the name of the bug with [Freetype], component Text, and just select the latest nonsense version from the list of nonsense versions. I stopped moving bugs from GNOME -> WebKit except in the case of simple crashers, since it's often very helpful to have the original reporter in the bug report.
Comment 9 Jean-François Fortin Tam 2015-07-17 18:31:52 UTC
> That is not what we do, because it defeats the point of CSS font fallback, 
> which is to allow the CSS to control the fallback.
> If you perform fontconfig matching on the first font, 
> the web page has no way to control the font fallback:
> fontconfig will _always_ find a match for any font you give it [...]
> So WebKit exhausts the entire list of fonts specified by the CSS
> before it uses fontconfig to find a different font.

Ah, I did not think of that... but that doesn't really change the issue, because I do not have a font actually called "sans serif" or "sans", strictly speaking!

The current implementation does this, if I'm guessing correctly:

1. Try Arial; no match
2. Try Helvetica; no match
3. Hit "sans-serif"; no match, because that's not actually a font, just an generic indication of a type of font, leading epiphany to #4:
4. Use the org.gnome.Epiphany.web "sans-serif-font" key, which happens to be "Sans 10" by default, which fc-match converts to "DejaVu Sans Book", hence the result you could see in Elad's screenshot (it was not just a hinting problem, but actually DejaVu being put instead of the "correct" font - indeed if you change the value of that dconf key while on that page you will see the render change significantly)

Sure, step #2 must happen if step #1 failed, but wouldn't it be logical for step #3 to imply a second pass, to ask for a match for #1? Thus the logic would become:

1. Try Arial; no match
2. Try Helvetica; no match
3. Hit "sans-serif"; no match, but assume that the previous choices were more indicative of what the designer actually wanted, so...
4. Ask fc-match for "Arial", get the final fallback result (which turns out to be Liberation Sans). Epic Win, and no hardcoding hacks required!
Comment 10 Michael Catanzaro 2015-07-17 22:03:25 UTC
This looks very similar to https://bugs.webkit.org/show_bug.cgi?id=77437 so let's Let's move discussion there (where the relevant developers can see it!). But my short answer to your post is that once you reach sans-serif, that's a request by the web page to use the system default sans font.
Comment 11 Michael Catanzaro 2015-07-17 22:25:25 UTC
Actually that bug is different: that one covers the case where the page does not specify a fallback like sans-serif. In our case, the page does specify the fallback.
Comment 12 Michael Catanzaro 2015-07-17 23:25:03 UTC
(In reply to Jean-François Fortin Tam from comment #9)
> 1. Try Arial; no match
> 2. Try Helvetica; no match
> 3. Hit "sans-serif"; no match, but assume that the previous choices were
> more indicative of what the designer actually wanted, so...
> 4. Ask fc-match for "Arial", get the final fallback result (which turns out
> to be Liberation Sans). Epic Win, and no hardcoding hacks required!

The problem with this is that it's not compliant with the CSS spec: sans-serif is _always_ a match. Normal pattern matching should only occur if no generic is there, since the pattern could return a result that is far worse than the generic that the website explicitly requested.

Talking with Martin Robinson, I think we should make two changes:

1. In the case where a generic fallback like sans-serif is not specified, we should do pattern matching. That is https://bugs.webkit.org/show_bug.cgi?id=77437 which is not a priority for me, but I expect patches there would be reviewed promptly.

2. In any case, we should ideally have replaced Arial with Liberation Serif. There are two ways to do this:
  - Hardcoded list. Chrome does this; presumably Firefox too? Yuck.
  - Allow matching only for strong aliases. This is not currently possible but the fontconfig developers started working on it quite recently: see https://bugs.freedesktop.org/show_bug.cgi?id=19375 and the other bug it links to. 

So once that fontconfig bug is solved, we will use that new API to match up e.g. Arial to Liberation Sans without the possibility that the match will go horribly wrong. In the meantime we might consider using a hardcoded list, or we might find another workaround. You can CC yourself on the WebKit bug if you want to follow the action.

We definitely won't allow any other matching, because that's too far from the CSS spec, except in the case where there is no generic family at all.

There is also another bug here regarding the base64-encoded web fonts, that Elad founds, which still needs to be reported.
Comment 13 Michael Catanzaro 2015-07-17 23:26:47 UTC
Forgot to link: https://bugs.webkit.org/show_bug.cgi?id=147057
Comment 14 Michael Catanzaro 2015-08-01 17:45:26 UTC
(In reply to Michael Catanzaro from comment #8)
> (Hence you can be sure Firefox does not match Arial to Liberation Sans
> using fontconfig, but probably a hardcoded value, unless Arial is really the
> only font specified by the page.)

Turns out this is incorrect: Firefox definitely respects fontconfig aliases. I haven't looked at their code to see what exactly they're doing, though.

Thanks to your WebKit bug report, we now will respect "strong" fontconfig aliases, typically used for metric-compatible fonts, but not weak aliases. This is what future versions of Chrome will do. (Firefox seems to accept them both.)