[webkit-reviews] review granted: [Bug 170119] Try to normalize variation ranges : [Attachment 305801] Patch
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed Mar 29 15:45:50 PDT 2017
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?
More information about the webkit-reviews
mailing list