1666125 - synthetic bolding is used when font-family: "Hiragino Kaku Gothic ProN W3"; font-weight: bold with gfx.e10s.font-list.shared=true

Status: RESOLVED INVALID

(Core :: Layout: Text and Fonts, defect)

Description

[rinsuki]

Attachment: reproduce-bug-with-hiragino-kaku-gothic-pron.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:80.0) Gecko/20100101 Firefox/80.0

Steps to reproduce:

Steps to Reproduce:

1. Use font-family: "Hiragino Kaku Gothic ProN W3"; to Bold font. like this style: font-family: "Hiragino Kaku Gothic ProN W3"; font-weight: bold;
2. Enable gfx.e10s.font-list.shared in about:config (note: from 20200907214307 nightly, this config is enabled by default. see https://hg.mozilla.org/mozilla-central/rev/17b0768200fb16f96e26400b11c9ee0de53d8828 )

Reproduced Environment:
macOS Catalina 10.15.6
Firefox 80.0.1 (current stable) ~ 82.0a1 (2020-09-19) (nightly, current latest)

Note: in Chrome 85.0.4183.102, this stylesheet won't make text bold.

Actual results:

User see synthetic bolding font, it's generated from weight=300 of Hiragino Kaku Gothic ProN. It looks weird.

Note: This behaviour is same as Safari 14.0 in macOS 10.15.6.

Expected results:

User see proper bold font (weight=600 of Hiragino Kaku Gothic ProN) instead of synthetic bolding font.

Note: if gfx.e10s.font-list.shared config is false, this behaviour.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Jonathan Kew [:jfkthame]]

Hmm, it's interesting that this behaves differently, but I don't think it is really a bug -- if anything, the old behavior was wrong. If the CSS explicitly names the W3 face, then that's what we use.

For the browser to choose the appropriate face (W3 or W6) according to font-weight, the right thing approach would be to write font-family: "Hiragino Kaku Gothic ProN", to request the entire family that includes multiple weights. If you request a "family" that consists of just an individual weight, then that exact face will be used, and then synthetic bold may be applied if necessary to satisfy the requested font-weight.

(In general, requesting an individual face like this just shouldn't work at all, because the font-family property takes font family names, not font face names. So for example, saying font-family: "Times Bold", Helvetica will result in using Helvetica, as "Times Bold" is not a family name at all. But some font families include alternate "family" names for individual styled faces, often as a legacy of older systems that could not properly select by style properties, and if such names are present -- as in the case of the W3/W6 faces here -- we try to honor them.)

Comment 3

[rinsuki]

Indeed, the new behavior is semantically correct. However, some real-world websites (perhaps unintentionally) specify W3 face in font-family.

Also, a search on Google reveals that several articles recommended the font-family with W3 for Hiragino Kaku Gothic ProN a few years ago.

https://www.google.com/search?client=firefox-b-d&q=font-family+%22%E3%83%92%E3%83%A9%E3%82%AE%E3%83%8E%E8%A7%92%E3%82%B4+ProN+W3%22

(Note: ヒラギノ角ゴ is japanese name of Hiragino Kaku Gothic)

Presumably, these Websites are not intended to use synthetic bolding. When this happens, I don't know whether we should take semantic correctness or beauty of rendering results. What do you think about this? also, is there a similar precedent?

Comment 4

[Jonathan Kew [:jfkthame]]

Given that the behavior in both Safari and Chrome seems to be similar to the "new" behavior (with the shared fontlist pref enabled), I think we should accept that this is correct. The result may be inferior to what they'd get by using the correct font-family name (without the face weight suffix), but it's still readable, and it matches other browsers.

Presumably if many authors noticed and cared about this, they'd want to correct their CSS so as to get the proper bold face in all browsers; it's not just an issue for Firefox.

The previous behavior in Firefox was a quirk that resulted from how "legacy" family names were implemented, but wasn't really correct. Indeed, if I view the testcase with Firefox 80, the columns styled with "Hiragino Kaku Gothic ProN W3" and "Hiragino Kaku Gothic ProN W6" look exactly the same, which doesn't make sense as one has explicitly asked for the lighter face, and the other has asked for the bolder one.

So, in my opinion: this isn't a bug, and as the change actually aligns us more closely with other browsers, there's little motivation to try and maintain the previous (incorrect) behavior.