Re: [css3-fonts] duplication and @font-face rules

On Thursday 2008-11-06 10:42 -0800, L. David Baron wrote:
> 3. Handling multiple @font-face rules defining the same fonts
> =============================================================
> 
> The third issue is somewhat similar to the second, except it
> involves some additional forward-compatibility issues:
> 
> Given two @font-face rules that describe the same font but have
> different 'src' descriptors, which fonts are used?  For example:
> 
> @font-face {
>   font-family: "Foo";
>   src: url(a.ttf);
> }
> 
> @font-face {
>   font-family: "Foo";
>   src: url(b.ttf);
> }
> 
> body { font-family: "Foo", Arial, sans-serif; }
> 
> In this case, does the search for glyphs look in:
>  (1) a.ttf, then b.ttf, then Arial, then other sans-serif fonts
>  (2) b.ttf, then a.ttf, then Arial, then other sans-serif fonts
>  (3) a.ttf, then Arial, then other sans-serif fonts
>  (4) b.ttf, then Arial, then other sans-serif fonts
> ?
> 
> Right now WebKit nightlies appear to do (2) and Gecko nightlies
> appear to do (4).
> 
> I think I prefer (4) because:

As I said before I meant to say that I prefer (2).

(John also pointed out in
http://lists.w3.org/Archives/Public/www-style/2008Nov/0463.html that
Safari 3.1 does (4).)

> (a) @font-face rules that are identical might actually differ in
> descriptors that the user-agent doesn't understand or can't parse.
> If these descriptors are like 'font-weight', then in doesn't matter
> what the behavior is, and authors can work around the lack of
> support for those descriptors by choosing one of the fonts over the
> other by putting the @font-face rules in a particular order
> (whichever way they want), no matter which solution is chosen (as
> long as the solution is consistent across browsers).  However, if
> the unknown descriptor (or descriptor with an unknown value) is one
> like 'unicode-range', the user-agent is clearly better using both of
> the sources provided.

John asked me to explain this forward-compatibility problem in a
little more detail.

Doing (4) rather than (2) requires that we define a notion of
equality for @font-face rules (that doesn't check equality of
'src'), and then throw out any rules that are equal to a later rule.
I'm very uncomfortable with doing this because the notion of
equality can change over time if we add new descriptors.

For example, let's suppose that the 'font-stretch' and
'unicode-range' descriptors didn't exist in the current level of
css3-fonts, but we wanted to add them in the next one.  (This is a
somewhat realistic example because Firefox 3.1 will ship without
support for these, and according to other messages in this thread,
Safari 3.1 shipped without 'unicode-range' but it works in WebKit
nightlies.)


Suppose that a style sheet split up a font and described that split
using 'unicode-range':

@font-face {
  font-family: BigFont;
  /* don't quote me on these character ranges! */
  unicode-range: U+0000-036F;
  src: url(BigFontLatin.ttf);
}

@font-face {
  font-family: BigFont;
  unicode-range: U+0370-03FF;
  src: url(BigFontGreek.ttf);
}

@font-face {
  font-family: BigFont;
  unicode-range: U+2E80-A4FF;
  src: url(BigFontCJK.ttf);
}

In an implementation that didn't support 'unicode-range' and did
(4), this font would only get used for CJK characters.  But once
that implementation started supporting 'unicode-range', all three
would start getting used.  However, if it did (2) all along, this
wouldn't be a problem, and all three parts of the font would get
used (although more could be downloaded than necessary if all three
parts weren't needed).


If an implementation, in turn, didn't support 'font-stretch', then
the effect of the following rules:

@font-face {
  font-family: FontWithStretchVariants;
  font-stretch: normal;
  src: url(FWSV-Normal.ttf);
}

@font-face {
  font-family: FontWithStretchVariants;
  font-stretch: expanded;
  src: url(FWSV-Expanded.ttf);
}

@font-face {
  font-family: FontWithStretchVariants;
  font-stretch: collapsed;
  src: url(FWSV-Collapsed.ttf);
}

would be pretty much the same between options (2) and (4):  the
implementation would use the glyphs from the last of the fonts
listed, which means the author is probably better off listing the
'font-stretch: normal' font last.


So I think we should do (2) for forward-compatibility reasons, since
it makes a big difference if we introduce new descriptors like
'unicode-range' in the future, but it doesn't make a significant
difference if we introduce new descriptors like 'font-stretch' in
the future.

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

Received on Tuesday, 18 November 2008 16:02:58 UTC