Cyrillic font rendering issue with FF44 on Linux

NEW
Assigned to

Status

()

Core
Graphics: Text
P3
normal
2 years ago
7 months ago

People

(Reporter: Pavel, Assigned: jfkthame)

Tracking

({regression})

44 Branch
x86
Linux
regression
Points:
---

Firefox Tracking Flags

(firefox45 wontfix, firefox46 wontfix, firefox47 wontfix, firefox48 wontfix, firefox-esr45 wontfix)

Details

(Whiteboard: [gfx-noted])

Attachments

(4 attachments)

(Reporter)

Description

2 years ago
Created attachment 8721776 [details]
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.
(Reporter)

Updated

2 years ago
OS: Unspecified → Linux
Hardware: Unspecified → x86

Updated

2 years ago
Component: Untriaged → Graphics: Text
Product: Firefox → Core
(Assignee)

Comment 1

2 years ago
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.
(Reporter)

Updated

2 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INVALID
(Reporter)

Updated

2 years ago
Resolution: INVALID → WORKSFORME
(Assignee)

Comment 2

2 years ago
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.
Flags: needinfo?(login.spv)
(Reporter)

Comment 3

2 years ago
(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).
Status: RESOLVED → UNCONFIRMED
Flags: needinfo?(login.spv)
Resolution: WORKSFORME → ---
(Assignee)

Comment 4

2 years ago
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.)
Blocks: 1180560
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
(Reporter)

Comment 5

2 years ago
Created attachment 8721918 [details]
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.
(Reporter)

Comment 6

2 years ago
Created attachment 8721920 [details]
Firefox 43 default font settings - expected results

Expected results - previous release Firefox 43 screenshot with default font settings.
Whiteboard: [gfx-noted]
[Tracking Requested - why for this release]: nominating to track since this is a regression starting in Firefox 44 (too late for that release).
status-firefox45: --- → affected
status-firefox46: --- → affected
status-firefox47: --- → affected
status-firefox48: --- → affected
status-firefox-esr45: --- → affected
tracking-firefox45: --- → ?
tracking-firefox-esr45: --- → ?
Cam, another one where we could use some insight.  Jonathan, is this something you can handle?
Assignee: nobody → jfkthame
Flags: needinfo?(cam)
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?
Flags: needinfo?(cam)

Updated

2 years ago
status-firefox45: affected → wontfix
status-firefox46: affected → wontfix
status-firefox47: affected → wontfix
status-firefox48: affected → wontfix
status-firefox-esr45: affected → wontfix
tracking-firefox45: ? → ---
tracking-firefox-esr45: ? → ---
Flags: needinfo?(bugs)

Comment 10

2 years ago
This one may also depend on bug 1245811. Jonathan is taking a look at both bugs.
Flags: needinfo?(bugs)
(Assignee)

Comment 11

2 years ago
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.
(Assignee)

Comment 12

2 years ago
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!
Flags: needinfo?(login.spv)
(Reporter)

Comment 13

2 years ago
(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.
Flags: needinfo?(login.spv)
(Reporter)

Comment 14

2 years ago
Created attachment 8741224 [details]
Firefox 48.0a1 Nightly with default font setting

Added screenshot Firefox 48.0a1 Nightly with default font setting.
(Assignee)

Comment 15

2 years ago
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.
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.