[Webkit-unassigned] [Bug 120499] Font-faces with different styles should not be mixed in a CSSSegmentedFontFace

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Jun 5 01:53:26 PDT 2017


Dominik Röttsches (drott) <d-r at roettsches.de> changed:

           What    |Removed                     |Added
                 CC|                            |d-r at roettsches.de,
                   |                            |mmaxfield at apple.com

--- Comment #1 from Dominik Röttsches (drott) <d-r at roettsches.de> ---
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.

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170605/1dee244e/attachment.html>

More information about the webkit-unassigned mailing list