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

Also sprach John Daggett:

 > > I'll start with the easiest of the three issues:  when the same
 > > descriptor appears twice in an @font-face rule, which one or ones
 > > matter?  
 > > 
 > > CSS 2.0 is clear on this:
 > > 
 > >   # If a font descriptor is duplicated, the last occurring
 > >   # descriptor wins and the rest must be ignored.
 > 
 > This makes the most sense to me.

Agreed.

 > > 2. Handling of lists of values of the 'src' descriptor
 > > ======================================================
 > > 
 > > The second issue is that the spec doesn't describe how a user agent
 > > should process multiple values of the 'src' descriptor.  In
 > > particular, when the 'src' descriptor is a list of values, there
 > > seem to be two reasonable possibilities:
 > > 
 > >   (A) The user agent uses the first of those values for which it has
 > >   a usable font (e.g., a local() font that is present or a url()
 > >   that is in a format it supports) and ignores the rest.
 > > 
 > >   (B) The user agent uses all of the values for which it has a
 > >   usable font, picking each glyph from the earliest in the list that
 > >   has a glyph for the character.
 > > 
 > > (B) seems like it has some advantages, particularly when local() and
 > > src() are combined, and the font available locally may have more or
 > > fewer glyphs in it depending on what the user has chosen to install.
 > > It also feels more CSS-like to me (which could mean it fits author
 > > expectations better, although maybe not).

Agreed, it feels more CSS-like -- it's iso-morphic to the
comma-separated list on 'font-family'.

 > > (A) seems like it may have some advantages in terms of speed or
 > > bandwidth usage.
 > > 
 > > However, current implementations in WebKit nightlies and in Gecko
 > > nightlies seem to do (A).
 > 
 > I actually think it's important to separate font loading behavior from
 > font fallback, so that web authors have more control over when fonts are
 > downloaded and used.  Method (B) may seem more like normal CSS fallback
 > but it gives authors less control.
 > 
 > Example: use an SVG font as a substitute for when Futura not available
 > locally
 > 
 >   @font-face {
 >     font-family: MyFutura;
 >     src: local(Futura-Medium), url(fonts/MyGeometricModern.svg) format("svg");
 >   }
 > 
 >   body { font-family: MyFutura, sans-serif; }
 > 
 > With method (B), user agents supporting SVG fonts would *always*
 > download the SVG font in fallback situations, even if the web author
 > already knew that both fonts supported the same set of characters.

That's only a slight inconvenience, I believe. And you could get
around it by saying:

   @font-face {
     font-family: MyFutura1;
     unicode-range: U+A5, U+4E00-9FFF, U+30??, U+FF00-FF9F;
     src: local(Futura-Medium);
   }

   @font-face {
     font-family: MyFutura2;
     unicode-range: U+A5, U+4E00-9FFF, U+30??, U+FF00-FF9F;
     src: url(fonts/MyGeometricModern.svg) format("svg");
   }

   * { font-family: MyFutura1, MyFutura2 }


 > Example: set up a font for use with Arabic text that works across
 > different platforms
 > 
 >   @font-face {
 >     font-family: Lateef;
 >     src: url(../fonts/LateefRegAAT.ttf) format("truetype-aat"), 
 >          url(../fonts/LateefRegOT.ttf) format("opentype");
 >   }
 > 
 >   body { Lateef, sans-serif; }
 >   
 > In this case, user agents under Mac OS X would use the AAT font while
 > user agents on other platforms would skip the AAT font and use the
 > OpenType font.  In the case of fallback for non-Arabic text, method (B)
 > would require both fonts to be downloaded under Mac OS X.

Ditto.

 > Example: set up an alias for Japanese fonts on different platforms
 > 
 >   @font-face {
 >     font-family: Japanese;
 >     src: local(Meiryo), local(HiraKakuPro-W3), local(IPAPGothic);
 >   }
 > 
 >   body { Helvetica, Japanese, Arabic, sans-serif; }
 >   
 > Method (A) allows a simple way to just lookup a character in one font
 > per possible script.  Method (B) requires a lot of extra lookups.
 > 
 > Method (B) mimics normal font fallback, so it's possible to get the same
 > results with a normal font-family list using fonts defined by simple
 > @font-face rules.  Method (A) can't be simulated in a user agent that
 > uses method (B).

This is a good argument. I also like the simplicity of it.

Another argument for (A) is that you could list alternative sources
for the same font file:

  @font-face {
    font-family: foo;
    src-fallback: url(http://server1.com/foo.ttf), url(http://server2.com/foo.ttf)
  }

One arguement for (B) is that Prince has implemented it this way and
that it uses it in the default style sheet:

  @font-face {
    font-family: sans-serif;
    src: local("Arial"), local("Helvetica"), local("OpenSymbol"), local("DejaVu Sans")
  }

If we remove the fallback behavior, glyphs from "OpenSymbol" are
unlikely to ever be used. One could argue that, since this is a kind
of init-file, a different descriptor could be used, e.g.:

  @font-face {
    font-family: sans-serif;
    src-fallback: local("Arial"), local("Helvetica"), local("OpenSymbol"), local("DejaVu Sans")
  }

This way we could support both scenarios.


 > > 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:
 > > 
 > > (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.
 > > 
 > > (b) It has more similarity to the way descriptors like
 > > 'unicode-range' are handled.
 > > 
 > > (c) Again, it seems somewhat more CSS-like to me.
 > 
 > I agree, for two @font-face rules that specify the same set of font
 > descriptor values with different src values, the first rule should
 > effectively be ignored.  I'm surprised that WebKit uses (2) that doesn't
 > make a lot of sense.

It's a hassle to have to record seemingly duplicate @font-faces, but
with extensibility in mind, 2 may actually make more sense. 4 is
simpler, though. I'm torn.

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Wednesday, 12 November 2008 17:41:48 UTC