|Summary:||Try to normalize variation ranges (to fix overly heavy fonts on facebook.com)|
|Product:||WebKit||Reporter:||Myles C. Maxfield <mmaxfield>|
|Component:||Text||Assignee:||Myles C. Maxfield <mmaxfield>|
|Severity:||Normal||CC:||dino, jonlee, mmaxfield, simon.fraser, thorton, webkit-bug-importer|
|Version:||WebKit Nightly Build|
|Bug Depends on:|
Description Myles C. Maxfield 2017-03-27 08:59:30 PDT
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.
Comment 5 Simon Fraser (smfr) 2017-03-29 15:45:50 PDT
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?
Comment 6 Myles C. Maxfield 2017-03-29 16:12:13 PDT
Committed r214572: <http://trac.webkit.org/changeset/214572>