[Linux] Open Sans diacritics render incorrectly (upstream library suspected)

UNCONFIRMED
Unassigned

Status

()

Core
Graphics: Text
P3
normal
UNCONFIRMED
a year ago
3 months ago

People

(Reporter: marcin, Unassigned)

Tracking

47 Branch
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [gfx-noted])

Attachments

(1 attachment)

(Reporter)

Description

a year ago
Created attachment 8768834 [details]
open_sans_ff47.png

Steps to reproduce:

  1. Go to Google Fonts
  2. Find "Open Sans" font.
  3. Enter "aą eę" as example text.
  4. Set a font size of 12px or 26px.

Effect:

  Letters with accents differ in shape from letters without.

I have originally discovered this problem in Chromium around version 38-40 and reported it there. At that time Firefox has been rendering the same font correctly, but recently that has changed. I suspect that the bug must be connected to some common library used by both browsers and perhaps the font itself.

OS: Linux Mint 17.3 (Ubuntu 14.04.3)
I suspect this is related to the fact that Google Fonts is splitting the Open Sans font into two separate resources, one for the basic Latin-1 character set and a separate one for additions such as ą and ę. And then (depending on your local font configuration) Freetype's hinting gets applied independently to the two faces, and if you're unlucky it ends up applying quite different hinting to glyphs that ought to be similar. For example, if the latin-extensions face doesn't have any of the basic (unaccented) glyphs, then Freetype's autohinter may not be able to do its usual analysis of key features that should be made consistent; or at least, that analysis will give quite different results than it would if the complete character set were hinted together.

The problem probably starts appearing in Firefox with the introduction of unicode-range support in @font-face; prior to that, Google Fonts probably served a single big font resource to Firefox because it was unable to manage the division across separate faces for different unicode subsets. Chromium had unicode-range earlier, and so the problem appeared there earlier.

You can probably "fix" this locally by modifying your system's font hinting preferences (fontconfig setup), though I don't know the details of what might help. Otherwise, I think it's an unfortunate side-effect of how Google Fonts chooses to deploy the font resources. If they didn't do the unicode-range split whereby some Latin glyphs are in one face, and other related extended-Latin glyphs are in a separate face, I doubt the inconsistency would occur.
(Reporter)

Comment 2

a year ago
Thank you for your in-depth analysis. When I serve the font myself with a single @font-face declaration the letters in question get hinted correctly.

Keeping the bug open, because ultimately it still needs fixing browser-side.
Whiteboard: [gfx-noted]
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.