- From: John Daggett <jdaggett@mozilla.com>
- Date: Tue, 18 Nov 2008 01:48:23 -0800 (PST)
- To: www-style@w3.org
> > 3. Handling multiple @font-face rules defining the same fonts > > ============================================================= > > > > 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 > > ? > > > > 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. One more addendum to this, Safari 3.1 actually has behavior (4) while the current Webkit nightly has behavior (2). I think this is an artifact of the how unicode-range is used by Webkit. The rules above are equivalent to: @font-face { font-family: "Foo"; src: url(a.ttf); unicode-range: U+0-7FFFFFFF; } @font-face { font-family: "Foo"; src: url(b.ttf); unicode-range: U+0-7FFFFFFF; } Safari 3.1, which implements unicode-range, uses only the unicode-range defined by the @font-face rule, the same as (4) above. The Webkit nightly is using an effective unicode-range which is the range defined in in the @font-face rule intersected with the range defined in the font data, thus it behaves like (2). I'm still a little concerned about how authors override fonts defined like this. John Daggett Mozilla Japan
Received on Tuesday, 18 November 2008 09:49:05 UTC