Font matching algorithm

BODY {font-family: genericfontfamily}

A UA chooses "Font A" as this.

Unfortunately, "Font A" lacks a glyph that has been

<blockquote cite="">
7. If there is a matching font face, but it doesn't
contain glyph(s) for the current character(s), and
     if there is a next alternative 'font-family' in
the font sets, then repeat from step 2 with the next
     alternative 'font-family'. ...
8.If there is no font within the family selected in 2,
then use the inherited or UA-dependent
     'font-family' value  

Thus if "Font A" lacks the glyph, then the UA will use
its UA-dependent font-family value.

It strikes me that this is wrong, since font-family:
genericfontfamily may match several fonts on the
user's computer, and that instead the UA should
substitute a different font within that
genericfontfamily (especially when the font it did
choose may well have been largely arbitrary).
Note the quote below has a different context:

<blockquote cite="">
UAs that
     implement intelligent matching may proceed to
examine other descriptors such as x-height,
     glyph widths, and panose-1 to identify a
different tentative font family. If there are matches
     all the remaining descriptors, then that is the
matching font face for the given element. The
     'font-family' descriptor that is reflected into
the CSS2 properties is the font family that was
     requested, not whatever name the intelligently
matched font may have. UAs that do not
     implement intelligent matching are considered to
fail at this step. 

It seems to me that the requirement for _all_ the
remaining descriptors could be overly restrictive.

@font-face {
lots of information about "font A"}
* {font-family: "Font A"}.

It seems to me that it would be better if Font A is
not available and there is no font that matches
exactly, for the UA to use the font whose panose
digits are closest to it.
Equally when you have * {font-family: "font a"}, if
the font chosen by the UA lacks the glyph requested,
the UA should use a font that is as similar as
possible to the requested font.
* {font-variant: small-caps}

This will cause a small-caps font to be used if
available (unless inappropriate because of the

But what if the small-caps font lacks glyphs for
uppercase (note that the glyphs are uppercase, but the
characters they represent are lowercase) letters (as
some such fonts do).

In this case the font matching algorithm states that
the result given "The dog" would be the T in a
completely different font from "he dog", since the
font lacks the T. This would result in a ridiculous

It seems that this is unacceptable, since the author
is not to know that the user's small-caps font happens
to lack glyphs for uppercase letters (it would be
acceptable with font-family: "Name of a small caps
font", because the fact that the font lacks the glyphs
is forseeable), and that therefore if the font lacks
glyphs for a particular case with font-variant:
small-caps, the opposite case should be used.

From Matthew Brealey ( (for law)or (for CSS))
Do You Yahoo!?
Bid and sell for free at

Received on Friday, 5 November 1999 07:08:34 UTC