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

On Wed, Nov 7, 2012 at 9:45 PM, John Daggett <jdaggett@mozilla.com> wrote:

>
> 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.
>

Do you include specific language that discusses this fallback behavior,
either in general or in a specific fashion? If not, then do you have
proposed language?


>
> 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
>
>