Bug 120499 – Font-faces with different styles should not be mixed in a CSSSegmentedFontFace

• Status: NEW
• Component: Layout and Rendering

[Ryosuke Niwa]

Consider merging https://chromium.googlesource.com/chromium/blink/+/7823ceba809d5c05bffeeb9e732e92fe76fab7e9

Before this patch, when a glyph for the character to be rendered is not
in the matched @font-face, glyph from other @font-face (with different
style) in the family or system font with the same name were used as fallback.
This behavior does not follow the font matching algorithm
(http://www.w3.org/TR/css3-fonts/#font-matching-algorithm):

"6. If no matching face exists or the matched face does not contain a glyph
    for the character to be rendered, the next family name is selected and
    the previous three steps repeated. Glyphs from other faces in the family
    are not considered."

This patch fixes the issue by changing CSSSegmentedFontFace to represent fonts
of single font traits. This also fixes a bug that the browser downloads fonts
for unused styles.

[Dominik Röttsches (drott)]

Myles, while looking at WebKit's code for variable fonts matching on style, stretch, weight, I came across this again. WebKit nightly r217775 still falls back across the boundaries of the initial style/stretch/weight "narrow-down". "Narrow-down" in the sense of the font matching algorithm, which aims to reduce the set of stretch, style, weight options down to one.

5.2.6 Font Style Matching https://drafts.csswg.org/css-fonts-3/#font-style-matching still says: 

"If no matching face exists or the matched face does not contain a glyph for the character to be rendered, the next family name is selected and the previous three steps repeated. Glyphs from other faces in the family are not considered. "

As far as I understand, the code in 
https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/css/CSSFontFaceSet.cpp#L431 just sorts the set, instead of narrowing it down to matching only one set of identical traits, so that the list of faces as members of CSSSegmentedFontFace would only differ in unicode-range.

https://codepen.io/anon/pen/GEgjyV is a reproduction: FF and Chrome only display the first 'a' in "Great Vibes", whereas WebKit nightly r217775 also shows the 'b' in Great Vibes, which it shouldn't do according to the font matching algorithm, since the @font-face which has unicode-range coverage for 'b' is of a different font-stretch: variant.

Could you perhaps comment on this issue? I'd like to find out whether we have the same understanding of the font matching algorithm. Thanks in advance.

[Radar WebKit Bug Importer]

<rdar://problem/32566994>

[Myles C. Maxfield]

You're right, we're not following the spec.

[Dominik Röttsches (drott)]

Thanks for taking a look.

[Ahmad Saleem]

Adding test case from Chrome / Blink commit in URL field.