W3C home > Mailing lists > Public > www-style@w3.org > November 2012

[css3-fonts] font matching should not load character map of all faces within a font family

From: John Daggett <jdaggett@mozilla.com>
Date: Wed, 7 Nov 2012 21:45:38 -0800 (PST)
To: www-style list <www-style@w3.org>
Message-ID: <112665355.7139275.1352353538490.JavaMail.root@mozilla.com>

The current WD of the CSS3 Fonts spec includes a detailed description
of the CSS font matching algorithm [1]. Included was this paragraph:

  WD font matching, step 4:

  4. If a font family match occurs, the user agent assembles
  the set of font faces in that family that contain a glyph
  for the character. It then narrows this matching set to a
  single face using other font properties in the order given below.

This details a process by which user agents scan the character maps of
*all* faces within a font family.  In addition to being a performance
burden for large families, this doesn't fit with the lazy-loading
model used for downloadable fonts.  The only way to match a font using
the step outlined above would be to first download all faces,
something that's obviously not desirable.

For these reasons, I changed the algorithm in the current editor's
draft [2] to be closer to what's described in CSS 2.1, which is to
simply pick a face based on the weight/width/slope attributes and then
test the character map of the chosen face.

  ED font matching, step 4:

  4. If a font family match occurs, the user agent assembles
  the set of font faces in that family and then narrows the
  set to a single face using other font properties in the
  order given below.

There's been some concern expressed within Mozilla about this.  Font
families don't always include the same set of codepoints across all
faces.  A normal face may include codepoints for a script that's not
supported in the italic face. It's generally best practice for all
faces to include the same character coverage but this isn't always
followed.  So the concern is that if a particular face is chosen that
doesn't support a given character, then fallback will occur.

Rather than introduce a complicated algorithm intended to address some
rare cases, I think it would make more sense to allow specific wiggle
room for user agents in a narrow set of cases.  For example, if the
normal face contains glyphs for Arabic but the italic face doesn't, we
can simply add wording that allows for fallback to the regular case in
this one situation.  This allows room for user agents to use better
heuristics in this situation, without imposing a burden that
negatively affects downloadable font performance.

Regards,

John Daggett

[1] http://www.w3.org/TR/2012/WD-css3-fonts-20120823/#font-style-matching
[2] http://dvcs.w3.org/hg/csswg/raw-file/b1a3980e9ac1/css3-fonts/Fonts.html
Received on Thursday, 8 November 2012 05:46:05 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:02 GMT