[webkit-reviews] review granted: [Bug 170119] Try to normalize variation ranges : [Attachment 305801] Patch

[bugzilla-daemon at webkit.org]

Simon Fraser (smfr) <simon.fraser at apple.com> has granted Myles C. Maxfield
<mmaxfield at apple.com>'s request for review:
Bug 170119: Try to normalize variation ranges
https://bugs.webkit.org/show_bug.cgi?id=170119

Attachment 305801: Patch

https://bugs.webkit.org/attachment.cgi?id=305801&action=review




--- Comment #5 from Simon Fraser (smfr) <simon.fraser at apple.com> ---
Comment on attachment 305801
  --> https://bugs.webkit.org/attachment.cgi?id=305801
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?