W3C home > Mailing lists > Public > www-style@w3.org > May 2015

[css-font-loading] load, check and testing for character coverage

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 1 May 2015 11:40:56 +1000
To: www-style@w3.org
Message-ID: <20150501014056.GB31849@wok.mcc.id.au>
I have a few questions/comments about load and check and the tests that
are done for character coverage using the sample text string.


The “find the matching font faces” algorithm will not include a matching
font face in its return value if its unicode-range does not include at
least one of the characters in the sample text string.  The algorithm
reads like it is written assuming that all font faces have a
unicode-range attribute, but that isn’t true for system fonts.  Should
we be checking the actual cmap of the font to see whether we have a
glyph for a given character?

For example, assuming Helvetica is a system font:

  document.fonts.check("16px Helvetica", "上")

Should this return false, because the font does not have a glyph for the
specified character, or should it return true as if we treated system
fonts as having an unspecified unicode-range (and therefore covering all


For that matter, should a font’s cmap ever affect how load or check
operate?  If I did:

  var f = new FontFace("Test", "url(Ahem.ttf)");
  f.load().then(function() {
    alert(document.fonts.check("16px Test", "上"));

per spec I think this should alert true.  It’s a little confusing, since
the author might think check is actually checking whether we will be
able to render the given string without using a fallback font, but
really what it’s doing is determining whether attempting to render that
string will need to kick off any loads.

I don’t know if the name “check” describes the behaviour of the method
clearly enough.


In line with the check method meaning “will loads be kicked off”, I
think it should return true if the list of matching font faces is empty.

Cameron McCormack ≝ http://mcc.id.au/
Received on Friday, 1 May 2015 01:41:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:31 UTC