1249973 - Cyrillic font rendering issue with FF44 on Linux

Status: RESOLVED WONTFIX

(Core :: Graphics: Text, defect, P3)

Description

[Pavel]

Attachment: Ugly font rendering with FF44

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20160106231616

Steps to reproduce:

Since FF44 release I have ugly cyrillic font rendering on some websites, for instance on http://minfin.ru/ru/


Actual results:

Please see attached file.


Expected results:

With previous release FF43 this issue not happens.

Comment 1

[Jonathan Kew [:jfkthame]]

If you go to about:config, find the option "gfx.font_rendering.fontconfig.fontlist.enabled" and toggle it to FALSE, and then quit and restart Firefox, does that fix things?

If so, that indicates you are seeing a problem triggered by bug 1180560.

Comment 2

[Jonathan Kew [:jfkthame]]

Why did you mark this as resolved -- does that mean you tried the suggestion from comment 1, and that "fixed" the rendering for you?

If so, the problem isn't really resolved; that's a workaround, and the problem is likely to reappear when the old code is removed altogether.

Comment 3

[Pavel]

(In reply to Jonathan Kew (:jfkthame) from comment #2)
> Why did you mark this as resolved -- does that mean you tried the suggestion
> from comment 1, and that "fixed" the rendering for you?
> 
> If so, the problem isn't really resolved; that's a workaround, and the
> problem is likely to reappear when the old code is removed altogether.

Changing option "gfx.font_rendering.fontconfig.fontlist.enabled" to false fixed rendering, but in this case fonts looks different compared to FF43 with no change option (don't know how to attach screenshots with my comment).

Comment 4

[Jonathan Kew [:jfkthame]]

OK, we should mark this as a regression from bug 1180560; it has apparently disrupted the font selection for Cyrillic on your system.

(If you have additional screenshots to attach, you can do that using the "Add an attachment" link just below the existing attachment.)

Comment 5

[Pavel]

Attachment: Firefox 44 with "gfx.font_rendering.fontconfig.fontlist.enabled" toggled to FALSE

Firefox 44 example screenshot with "gfx.font_rendering.fontconfig.fontlist.enabled" toggled to FALSE.
Cyrillic font has better rendering but it looks different compared to Firefox 43 with default font settings.

Comment 6

[Pavel]

Attachment: Firefox 43 default font settings - expected results

Expected results - previous release Firefox 43 screenshot with default font settings.

Comment 7

[u279076]

[Tracking Requested - why for this release]: nominating to track since this is a regression starting in Firefox 44 (too late for that release).

Comment 8

[Milan Sreckovic [:milan] (needinfo for best results)]

Cam, another one where we could use some insight.  Jonathan, is this something you can handle?

Comment 9

[Cameron McCormack (:heycam)]

It seems like there might be two issues: one is the font selection (though I'm not sure why the font selection has changed with the pref false, unless we made some changes between 43 and 44 in the old font selection code), and another is the rendering of the glyphs from what looks like the same font (comparing Fx 43 and Fx 44 with pref enabled).  Does that sounds right Jonathan?

Comment 10

[Jet Villegas (inactive)]

This one may also depend on bug 1245811. Jonathan is taking a look at both bugs.

Comment 11

[Jonathan Kew [:jfkthame]]

As comment 9 points out, it looks like there may be multiple issues here. The fix in bug 1245811 should help with font selection; currently, the new fontconfig font-list code is known to be buggy, and in certain cases will miss what fontconfig is trying to specify and hit fallbacks instead.

Another factor could be that the site in the screenshot is using a webfont; if that was running into the stricter validation introduced in FF44 (see bug 1244693), that would explain a 43/44 difference even with the old font-list code. (If that was the case, it may be fixed by now, as the Google Fonts folk have been fixing issues on their side.)

It looks like there's also something going on with font rendering options (perhaps hinting settings?). Offhand, I'm not sure why that would be.

So... let's revisit this once bug 1245811 is landed, and reconfirm what parts of the problem may remain at that point.

Comment 12

[Jonathan Kew [:jfkthame]]

Pavel, could you please re-test with the latest Nightly version from https://nightly.mozilla.org/ and see whether the behavior is changed at all as a result of bug 1245811? Thanks!

Comment 13

[Pavel]

(In reply to Jonathan Kew (:jfkthame) from comment #12)
> Pavel, could you please re-test with the latest Nightly version from
> https://nightly.mozilla.org/ and see whether the behavior is changed at all
> as a result of bug 1245811? Thanks!

I have tested with latest Nightly and see no difference compared to Firefox 44-45.

Comment 14

[Pavel]

Attachment: Firefox 48.0a1 Nightly with default font setting

Added screenshot Firefox 48.0a1 Nightly with default font setting.

Comment 15

[Jonathan Kew [:jfkthame]]

OK, I think I've understood what's going on here, and why things changed with the Firefox 44 update. (And unfortunately, I'm not sure there's anything we can do on our side to "fix" things -- but see the explanation that follows.)

The minfin.ru site is using the Google Fonts service to provide the fonts for its main body text, headings, etc -- specifically, it's using the Open Sans family. Exactly what this means, however, changed in Firefox 44 because we enabled support for the unicode-range descriptor (bug 1119062). And the Google Fonts API code sniffs the browser version, and serves different CSS and font resources depending on whether unicode-range is supported or not.

So in Firefox 43, we get a CSS file (from Google Fonts) that includes rules such as:

@font-face {
  font-family: 'Open Sans';
  font-style: normal;
  font-weight: 400;
  src: local('Open Sans'), local('OpenSans'), url(http://fonts.gstatic.com/s/opensans/v13/K88pR3goAWT7BTt32Z01m5Bw1xU1rKptJj_0jans920.woff2) format('woff2');
}

which delivers the complete Regular face of Open Sans as a single font file, and that's what you see in the body text of the minfin.ru site.

With Firefox 44 (and later), however, Google serves an alternative version of the CSS with separate rules for various subsets of the font:

/* cyrillic */
@font-face {
  font-family: 'Open Sans';
  font-style: normal;
  font-weight: 400;
  src: local('Open Sans'), local('OpenSans'), url(http://fonts.gstatic.com/s/opensans/v13/RjgO7rYTmqiVp7vzi-Q5UYX0hVgzZQUfRDuZrPvH3D8.woff2) format('woff2');
  unicode-range: U+0400-045F, U+0490-0491, U+04B0-04B1, U+2116;
}
/* latin */
@font-face {
  font-family: 'Open Sans';
  font-style: normal;
  font-weight: 400;
  src: local('Open Sans'), local('OpenSans'), url(http://fonts.gstatic.com/s/opensans/v13/cJZKeOuBrn4kERxqtaUH3ZBw1xU1rKptJj_0jans920.woff2) format('woff2');
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2212, U+2215, U+E0FF, U+EFFD, U+F000;
}

So now, the Cyrillic text on minfin.ru is rendered from the Cyrillic-subset face. That should be OK, in principle; AFAICS, it contains exactly the same glyphs as were in the complete font we got in FF43. However, depending on your font rendering (hinting & antialiasing) settings, freetype may end up rendering the glyphs differently when it's dealing with the subsetted version, because its autohinter will be looking at the complete repertoire of glyphs in the font to make some "global" decisions, and with the subsetted font, that will be based on a different data set than in the full font.

As for the different result you see with gfx.font_rendering.fontconfig.fontlist.enabled set to false: this happens because disabling the new fontconfig-fontlist also has the side-effect of disabling unicode-range support. So in that case, Google Fonts *thinks* we have unicode-range (based on the Firefox version), and serves us the CSS with the range-specific subsetted rules, but in fact we only use the last (Latin) subset they provide for each face. That doesn't include the Cyrillic characters, of course, so then font fallback kicks in and we end up rendering the Russian text from a different font altogether.


In short, then, I think things are behaving "as intended", and the result you get -- which I agree looks poor -- is an unfortunate result of how freetype handles that particular subsetted font. You may be able to solve this by adjusting the font rendering settings on your system (as it's a local system problem), e.g. with the Gnome Tweak Tool.

Another possible workaround would be to install the Open Sans font package locally, because then the Google Fonts CSS will simply use the (complete) local version instead of the (subsetted) downloads.

Comment 16

[Jonathan Kew [:jfkthame]]

Re-reading this, I think we should just close it as WONTFIX from a Firefox point of view. Comment 15 gives details of why the rendering looked poor, as a result of the interaction between Google Fonts resources and the local FreeType rendering settings, as well as possible workarounds. But there's not an actual Firefox bug to address here.