Support for OpenType Font Variations on Windows

Support for OpenType Font Variations on Windows

Enable support for variable fonts on Windows through using
SkFontMgr_Custom_Empty, a FreeType backed font blob only SkTypeface
factory (no access to system fonts). We will use a hybrid DirectWrite
and FreeType font stack on Windows for at least as long as most of
Windows versions we support with Chrome still do not have native support
for font variations.

Thanks to Ben Wagner for the help with enabling and prototyping this.

BUG=700926

[drott, 2017-03-30 11:37:53]

drott@chromium.org changed reviewers:
+ drott@chromium.org

[drott, 2017-03-30 11:37:54]

Nice, thanks!

[bungeman-skia, 2017-03-30 14:48:53]

On 2017/03/30 11:37:54, drott wrote:
> Nice, thanks!

Just curious, why is the win10 bot green? Is it possible the tests don't fail if
some named variation is chosen? To clarify, on win10 DirectWrite (currently)
variations are 'supported' but there is no API. When we open a font like this we
get back all of the named instances as if the font file were a ttc font file.
Currently I believe we just pick the first one because we don't really know what
else to do. If that first one happens to line up with something that makes the
test pass, the test will pass. Mostly just curious, because I expected all of
the 'NeverFixTest' to start to fail (by passing) on both win7 and win10.

[bungeman-skia, 2017-03-30 15:31:57]

Description was changed from

==========
Support for OpenType Font Variations on Windows

Enable support for variable fonts on Windows through using
SkFontMgr_Custom_Empty, a FreeType backed font blob only SkTypeface
factory (no access to system fonts). We will use a hybrid DirectWrite
and FreeType font stack on Windows for at least as long as most of
Windows versions we support with Chrome still do not have native support
for font variations.

Thanks to Ben Wagner for the help with enabling and prototyping this.

BUG=700926
==========

to

==========
Support for OpenType Font Variations on Windows

Enable support for variable fonts on Windows through using
SkFontMgr_Custom_Empty, a FreeType backed font blob only SkTypeface
factory (no access to system fonts). We will use a hybrid DirectWrite
and FreeType font stack on Windows for at least as long as most of
Windows versions we support with Chrome still do not have native support
for font variations.

Thanks to Ben Wagner for the help with enabling and prototyping this.

BUG=700926
==========

[bungeman-skia, 2017-03-30 15:33:04]

Closing this since the original https://codereview.chromium.org/2780133002/ can
now proceed. This CL was mostly for experimenting with DEPS and hooks.

[drott, 2017-03-30 15:55:37]

On 2017/03/30 at 14:48:53, bungeman wrote:
> On 2017/03/30 11:37:54, drott wrote:
> > Nice, thanks!
> 
> Just curious, why is the win10 bot green? Is it possible the tests don't fail
if some named variation is chosen? To clarify, on win10 DirectWrite (currently)
variations are 'supported' but there is no API. When we open a font like this we
get back all of the named instances as if the font file were a ttc font file.
Currently I believe we just pick the first one because we don't really know what
else to do. If that first one happens to line up with something that makes the
test pass, the test will pass. Mostly just curious, because I expected all of
the 'NeverFixTest' to start to fail (by passing) on both win7 and win10.

The test uses a web font. Win10 is green since the comparison between the
FreeType variation rendering and the DWrite non-variation reference rendering
happens to be identical. Whereas on Win7 there are slight antialiasing
differences. In the new CL, I am updating the reftest to make both glyphs be
produced by the variations font path, but using a dummy variation parameter
value.