Change font-weight-1 test to use webfonts

Change font-weight-1 test to use webfonts

Change the font-weight-1 test to use web fonts instead of embedding the
font files into DRT. This fixes the test flakiness, makes it run on all
platforms and avoids the need to includ it into DRT.

BUG=243520, 318515
R=dpranke@chromium.org

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=164460

[eae, 2014-01-03 20:47:58]

+thakis,eseidel

[Nico, 2014-01-03 21:05:17]

lgtm

Nice!

[eae, 2014-01-03 21:06:06]

Thanks!

[commit-bot: I haz the power, 2014-01-03 21:06:14]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/eae@chromium.org/110313004/1

[commit-bot: I haz the power, 2014-01-03 21:11:45]

Change committed as 164460

[eseidel, 2014-01-03 23:33:40]

LOVE IT.  LGTM

[eseidel, 2014-01-03 23:35:38]

IMO, we should consider removing Ahem from the binary as well and instead just
have it in /resources/ahem.css which loads /resources/ahem.ttf for you.

[Dirk Pranke, 2014-01-04 01:43:10]

On 2014/01/03 23:35:38, eseidel wrote:
> IMO, we should consider removing Ahem from the binary as well and instead just
> have it in /resources/ahem.css which loads /resources/ahem.ttf for you.

I think there are a lot of w3c tests that assume Ahem is installed; we'd have to
get them rewritten to use a webfont, and I don't know if there's much desire to
do that (or we could rewrite the tests as part of the import process).

Personally, I'd actually kinda rather see us move in the opposite direction,
which is to have the test binary use a fixed list of known (version-controlled)
fonts, and not rely on the system install at all.

The change looks good to me; that said, I'm curious as to why r156460 didn't fix
the flakiness and/or what the cause of the flakiness is. I fear this is just
papering over a bug somewhere ...

[eseidel, 2014-01-04 02:13:39]

The web as a whole seems to be moving away from the IE "web safe" font set and
towards Web Fonts.  Seems our testing should as well, no?  It's just the
addition of a single line of JS or CSS include depending on if you need the font
to be available synchronously or not.

That said, I don't have super strong opinions.  I do agree that we should be
using a consistent test environment, I'm just not sure it should include fonts
which the majority of users won't have installed, but maybe Ahem deserves its
special case. :)

[Dirk Pranke, 2014-01-04 02:31:12]

On 2014/01/04 02:13:39, eseidel wrote:
> The web as a whole seems to be moving away from the IE "web safe" font set and
> towards Web Fonts.  Seems our testing should as well, no?

Well, insofar as we need tests for webfonts, sure :)

The problem I'm looking to solve is the fact that we have pixel test baselines
that vary depending on the operating system (and version) you're running. Given
that we have lots and lots of tests that either assume particular fonts (e.g.,
Arial) are installed, or don't specify any particular fonts at all, this means
that we are either always going to be at the mercy of the OS, or we need to fix
something.

We could modify *every* test to specify the fonts we need, but doing that across
the 30k tests we currently have seems tantamount to hard-coding a list
somewhere. I could see an argument that doing this via explicit webfonts in the
test makes things, well, explicit. My main concern here would then be that
*always* using webfonts might slow things down, but that's probably easy to
test. 

Of course, we'd still want some tests that tested *not* using webfonts, and then
you'd still have the problem (just perhaps with a lot fewer baselines).

> That said, I don't have super strong opinions.  I do agree that we should be
> using a consistent test environment, I'm just not sure it should include fonts
> which the majority of users won't have installed, but maybe Ahem deserves its
> special case. :)

I would agree with this; Ahem is a special case because it is used so broadly in
the tests (both blink-specific ones and the W3C's). However, I don't actually
tend to like tests that use Ahem, and so maybe (?) we can deprecate it over time
...