1349308 - macOS Firefox does not apply proper letterspacing to the bold weights of the -apple-system-font

Status: RESOLVED FIXED

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

Description

[dangayle]

Attachment: Firefox rendering

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170316213829

Steps to reproduce:

I set up a group of identical paragraphs, with weights 100-900. Checked on Firefox and Chrome.

I have a codepen with the test here: http://codepen.io/dangayle/pen/RpMVqY


Actual results:

On Firefox, the font weight increases, but the letterspacing does not. This leads to very cramped spacing. On Chrome and Safari 

macOS Firefox 52.0.1 (64-bit)
http://i.imgur.com/RuXjVCH.png

macOS Chrome 57.0.2987.110 (64-bit)
http://i.imgur.com/lxmAxOf.png

macOS Safari Version 10.0.1 (12602.2.14.0.7)
http://i.imgur.com/2GVAoTk.png


Expected results:

The letterspacing should have increased as the weight increased, as seen in Chrome and Safari.

Comment 1

[dangayle]

Attachment: Chrome rendering

How the text renders in Chrome

Comment 2

[dangayle]

Attachment: Safari rendering

Comment 3

[dangayle]

I should mention, this is a pretty common default typeface these days. Medium, Github and others are using it as the first font in their stack.

Comment 4

[Bas Schouten (:bas.schouten)]

Jeff might have an idea on this.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

Jonathan's probably better than me.

Comment 6

[Jonathan Kew [:jfkthame]]

This is happening because the Apple system font (SFNS Text / SFNS Display, depending on size) is a variation font that uses named instances to produce the various weights. So even when font variations are not *explicitly* used, the various styles (Light, Regular, Bold, Heavy, etc) that are exposed as faces of the font family are in fact variation instances based on a single set of glyph outlines and metrics. But our harfbuzz shaping path does not pick up on that and apply the necessary variations to the glyph metrics, it just uses the base values directly from the metrics table.

We need to do some additional work to hook up variations to the harfbuzz backend (which will be needed before variations support is ready to roll out across platforms), but the simple, immediate fix here is to ensure that we use Core Text to get glyph metrics for these fonts. This is a code path we already use for certain cases ('sbix' fonts, and when font variations are explicitly enabled and applied via CSS), so we just need to use it in addition for these fonts where variations may *implicitly* be used.

Comment 7

[Jonathan Kew [:jfkthame]]

Attachment: Ensure we get glyph metrics via Core Text for variation fonts such as faces of SFNSText/Display

Comment 8

[Jonathan Kew [:jfkthame]]

Attachment: Reftest for -apple-system glyph metrics adjustment

It's hard to reftest this precisely, but here is a minimal test that checks we get different glyph widths for the bold vs regular faces, at least. This fails with current trunk code, but passes once the patch above is applied.

Comment 9

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/191cd228e2db1ed2e094e12b949652f67b697471
Bug 1349308 - Ensure we get glyph metrics via Core Text for variation fonts such as faces of SFNSText/Display. r=jrmuizel

https://hg.mozilla.org/integration/mozilla-inbound/rev/225cf847cd3a3c71938e493d9c144237b644a80d
Bug 1349308 - Reftest for -apple-system glyph metrics adjustment. r=jrmuizel

Comment 10

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/191cd228e2db
https://hg.mozilla.org/mozilla-central/rev/225cf847cd3a