Avoid referencing local copy of Ahem font in w3c-submitted reftests

NEW
Unassigned

Status

()

enhancement
P3
normal
a year ago
a year ago

People

(Reporter: dholbert, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(firefox61 affected)

Details

(Reporter)

Description

a year ago
We've got a bunch of w3c-submitted reftests that use a *local copy* of the "Ahem" font:
https://dxr.mozilla.org/mozilla-central/source/testing/web-platform/tests/css/vendor-imports/mozilla/mozilla-central-reftests/flexbox/support/Ahem.ttf
https://dxr.mozilla.org/mozilla-central/source/testing/web-platform/tests/css/vendor-imports/mozilla/mozilla-central-reftests/ruby/support/Ahem.ttf
https://dxr.mozilla.org/mozilla-central/source/testing/web-platform/tests/css/vendor-imports/mozilla/mozilla-central-reftests/text3/support/Ahem.ttf
https://dxr.mozilla.org/mozilla-central/source/testing/web-platform/tests/css/vendor-imports/mozilla/mozilla-central-reftests/variables/support/Ahem.ttf

We should perhaps move away from doing this? These submissions end up in WPT, which I think provides the Ahem font automatically. ("Aside from the Ahem font, fonts cannot be relied on to be .... installed" http://web-platform-tests.org/writing-tests/general-guidelines.html )

I suspect that in our own (non-WPT) reftest harness, Ahem cannot be relied on to be installed, which is why we're needing to provide it here. But as a result, we're adding clutter to our WPT-submitted tests.
There has been quite a bit of discussion around how Ahem should be handled.

I think dbaron or someone once raised that we should probably change all ahem flag to just use @font-face instead, since that flag exists simply because there wasn't such feature at that days.

But that's probably not very helpful given the current situation.
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.