Bug 170119 – Try to normalize variation ranges (to fix overly heavy fonts on facebook.com)

• Status: RESOLVED
• Resolution: FIXED
• Component: Text

[Myles C. Maxfield]

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.

[Myles C. Maxfield]

Created attachment 305698 [details]
Needs tests

[Myles C. Maxfield]

<rdar://problem/31234983>

[Myles C. Maxfield]

Created attachment 305711 [details]
Patch

[Myles C. Maxfield]

Created attachment 305801 [details]
Patch

[Simon Fraser (smfr)]

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?

[Myles C. Maxfield]

Committed r214572: <http://trac.webkit.org/changeset/214572>

[Myles C. Maxfield]

Committed r214585: <http://trac.webkit.org/changeset/214585>