W3C home > Mailing lists > Public > public-css-testsuite@w3.org > February 2017

Re: Tests with embedding, including of font resource with a @font-face rule

From: Geoffrey Sneddon <me@gsnedders.com>
Date: Fri, 17 Feb 2017 17:07:57 +0000
Message-ID: <CAHKdfMhHC62gWwBXAZs+EtumAm0-fbTiejfpUFoBFD5VEf8y6g@mail.gmail.com>
To: Gérard Talbot <css21testsuite@gtalbot.org>
Cc: Public CSS Test suite mailing list <public-css-testsuite@w3.org>, public-test-infra <public-test-infra@w3.org>
As a general aside, given we're at a point where merging csswg-test
into web-platform-tests is a matter of weeks in all probability,
policy things like this are probably best done on public-test-infra
(which I think has in theory included CSS all along? I have no real
idea).

On Thu, Feb 16, 2017 at 10:22 PM, Gérard Talbot
<css21testsuite@gtalbot.org> wrote:
> We have a bunch of tests, scattered in several test suites, which require a
> special, unique font (besides Ahem font) to use, to declare in such tests. I
> am trying to find the best way to declare @font-face in those tests. Right
> now, there is no guidelines that we are all following. I would like this to
> be standardized, normalized. We could therefore remove, drop use of the font
> flag (I can not remember if the font flag is supposed to be removed anyway
> from now on).

The font flag wasn't supposed to die (there are tests that can't use
@font-face, especially some of those testing font selection).

> Is declaring the .woff equivalent sufficient? I do not think so, furthermore
> if the .woff filesize is rather big.

I think WOFF suffices; I don't think anyone is likely to run the CSS
tests on anything that doesn't support WOFF at this point? (The policy
in general for web-platform-tests has been to stick to features that
the latest release of every major browser supports; WOFF is *well*
beyond that point, having reached it in 2011.)

> Here's what I propose, in a real test
>
> http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/font-face-mplus-1p-regular-test.html
>
> , involving a font face that we are already using in a dozen tests:
>
>   @font-face
>     {
>       font-family: "M+ 1p";
>       src: local("M+ 1p") , /* first try to use locally available and
> installed M+ 1p font */
>       url("support/mplus-1p-regular.woff") format("woff") , /* otherwise
> download its woff equivalent */
>       url("support/mplus-1p-regular.ttf") format ("truetype") ; /* otherwise
> use its TrueType font */
>
>       /* filesize of mplus-1p-regular.woff: 803300 bytes (784.5 KiloBytes)
> */
>
>       /* filesize of mplus-1p-regular.ttf : 1571848 bytes (1.5 MegaBytes) */
>
>       /*
>       mplus-1p-regular.ttf can be downloaded at, from
>
>       http://mplus-webfonts.osdn.jp/
>       */
>     }
>
> So, local would be first, .woff would be 2nd and then the font itself. The
> order between 2nd and 3rd is an ascending filesize order. And a link to
> download and install the font would be provided in a /* comment */ : that
> way, we would encourage fetching of locally installed font, which is always
> faster.
>
> I am looking for comments, feedback here.

One problem (and this isn't hypothetical: this caused problems in
Opera's CI years ago) is different versions of fonts causing issues,
and that is inherently worse with locally installed fonts. (The main
thing I remember causing problems were slight changes to metrics,
FWIW; obviously rare, but it does happen.) As such, I have a
preference *against* including local fallbacks.

I also don't think we need a link to download the font: we should have
the specific version of the font we rely on in the repository (which
obviously means it has been licensed such that we can redistribute it,
but we shouldn't be relying on any non-free licenses anyway).

This also reminds me that the build system means we can't just link to
everything in "/font" but need relative URLs in support, which means
we need fonts duplicated all over the place, ergh.

/g
Received on Friday, 17 February 2017 17:08:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 20 January 2023 19:58:22 UTC