- From: John Daggett <jdaggett@mozilla.com>
- Date: Wed, 21 Jan 2009 08:27:29 -0800 (PST)
- To: Michael Day <mikeday@yeslogic.com>, www-style <www-style@w3.org>
Hi Michael, Going back to your original posting on this back in November: http://lists.w3.org/Archives/Public/www-style/2008Nov/0259.html > It allows you to define font families with intelligent fallback: > > @font-face { > font-family: MyFont; > src: local("Times New Roman"), local("OpenSymbol"), ... > } > > In the Prince default style sheets we actually use this to predefine the > default font families such as "serif" and "sans-serif". This seems simple, but to really make this work you're going to need four rules to cover each of the four common style variations - normal, bold, italic and bold italic, since a single @font-face rule only defines a single *face* within a family. It really seems like you're interested in a way of aliasing a set of *families* so that wherever 'MyFont' is used, Times New Roman followed by OpenSymbol, etc. are substituted. Maybe: @font-alias { font-family: MyFont; alias: Times New Roman, OpenSymbol, ...; } Or maybe just something from CSS Variables? If the src is defined in such a way that user agents need to iterate over all the fonts in the list for font fallback, you lose the ability to control prioritized load behavior. In the example below, the author would like to use a locally available version of Futura but substitute a SVG font if it's not available, or an TrueType font otherwise. Assume for simplicity that each of these fonts has the same character map. @font-face { font-family: MyFutura; src: local(Futura Medium), url(MyGeometricModern.svg) format("svg"), url(FakeFutura.ttf) format("truetype"); } If you defined the src descriptor the way you propose, user agents that implement SVG fonts would *always* need to download the TrueType font, even if you separated these out into three separate @font-face rules and used MyFutura1, MyFutura2, MyFutura3 in all your font-family lists. For another example, complex scripts such as Arabic require special data within the font, and the necessary data varies across platforms, on Windows you need a font with OpenType Layout tables, on Mac OS you need a font with AAT tables. To support both platforms, the Arabic font Scheherazade (Jonathan Kew, please take a bow) comes in two forms, one for OpenType and one for AAT. @font-face { font-family: Scheherazade; src: url(ScheherazadeRegAAT.ttf) format("truetype-aat"), url(ScheherazadeRegOT.ttf) format("opentype"); } With src defined to iterate over the list during font fallback, the OpenType version of Scheherazade would always be downloaded, even though it wouldn't be needed on the Mac. > While it is possible to concoct scenarios involving combinations of > local fonts, downloaded fonts, different unicode-ranges and subtle > fallback behaviour to result in a perfect appearance, I wonder how > common these will actually be. For a wide variety of sites, there's probably not a whole lot of need for complicated scenarios involving unicode-range. Those sites can still use @font-face in a very simple way, no need to worry about unicode-range. But for sites that are multi-lingual, knowing which fonts to use for which locales and dealing with this complexity is an ongoing problem. Being able to use unicode-range in the way that it's currently implemented in WebKit is a huge win for these sites. Cheers, John Daggett Mozilla Japan
Received on Wednesday, 21 January 2009 16:28:12 UTC