Many fonts support ranges of the variation axes which don't play well with font-weight, stretch, and style. Let's see if we can fix them by applying a heuristic and normalizing he values.
Created attachment 305698 [details] Needs tests
<rdar://problem/31234983>
Created attachment 305711 [details] Patch
Created attachment 305801 [details] Patch
Comment on attachment 305801 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=305801&action=review > Source/WebCore/ChangeLog:3 > + Try to normalize variation ranges This title could be improved. > Source/WebCore/ChangeLog:4 > + https://bugs.webkit.org/show_bug.cgi?id=170119 Radar should go here. > Source/WebCore/ChangeLog:29 > + TrueType GX-style variation fonts use one particular scale for values on their > + weight/width/slope axes - usually the values lie between -1 and 1 on that scale. > + However, OpenType 1.8-style fonts use the CSS scale for values on these axes. > + For the purposes of font selection, these values need to lie on the same scale. > + However, when font selection is completed and the variation values are actually > + being applied to the fonts, values which lie on the font's actual scale need to > + be applied. This patch adds normalize*() and denormalize*() functions to perform > + both of these operations. > + > + The conversion itself between the two scales isn't an exact mapping. Mapping > + slope is just a linear relationship with 0deg <=> 0 and 20deg <=> 1 (as per the > + CSS Fonts spec). Mapping widths is similar, it uses a 2-component piecewise > + linear relationship which includes the values given in the Microsoft OpenType > + spec for the OS/2 table's usWidthClass field. Weights are more difficult, so I > + plotted the CSS weights and the GX-style weights for every style of San > + Francisco, saw that the relationship appears to be linear, and ran a linear > + regression to compute the line equation. > + > + As for the actual discrimination of determining whether a font is a GX-style > + font or not, we can use the presence of the 'STAT' table. This table didn't > + exist when GX fonts were being created, and OpenType 1.8 variable fonts are > + required to have this table. Doesn't say "Facebook" anywhere. Please describe the user-facing symptom. > Source/WebCore/platform/graphics/cocoa/FontCacheCoreText.cpp:451 > +// FIXME: Get the real values from Core Text. Is there a radar you can reference?
Committed r214572: <http://trac.webkit.org/changeset/214572>
Committed r214585: <http://trac.webkit.org/changeset/214585>