Bug 170119

Summary: Try to normalize variation ranges (to fix overly heavy fonts on facebook.com)
Product: WebKit Reporter: Myles C. Maxfield <mmaxfield>
Component: TextAssignee: Myles C. Maxfield <mmaxfield>
Status: RESOLVED FIXED    
Severity: Normal CC: dino, jonlee, mmaxfield, simon.fraser, thorton, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 162815    
Attachments:
Description Flags
Needs tests
none
Patch
none
Patch simon.fraser: review+

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 1 Myles C. Maxfield 2017-03-28 20:18:41 PDT
Created attachment 305698 [details]
Needs tests
Comment 2 Myles C. Maxfield 2017-03-28 20:19:47 PDT
<rdar://problem/31234983>
Comment 3 Myles C. Maxfield 2017-03-29 00:09:04 PDT
Created attachment 305711 [details]
Patch
Comment 4 Myles C. Maxfield 2017-03-29 15:38:21 PDT
Created attachment 305801 [details]
Patch
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>
Comment 7 Myles C. Maxfield 2017-03-29 17:37:42 PDT
Committed r214585: <http://trac.webkit.org/changeset/214585>