- From: John Daggett <jdaggett@mozilla.com>
- Date: Tue, 15 Feb 2011 18:05:15 -0800 (PST)
- To: Eric Muller <emuller@adobe.com>
- Cc: David Berlow <dberlow@fontbureau.com>, www-font@w3.org, www-style list <www-style@w3.org>
Eric Muller wrote: > > For fonts loaded via @font-face rules, authors define what > > weight/width values are assigned to individual faces, there's > > no reference to any weight/width data in the font itself, > > only what is defined in the @font-face rules. So unless an > > author is using more than 9 weights simultaneously, that's > > not much of a limitation currently. > > Except that the whole point of having font description matching > is to support fallback, and that you may then have to fallback > on a font that is not described by an @font-face rule. This > implies that This implies a broad agreement on the meaning of > the font description. Unlike the rules for matching plaform font sets that vary across platforms, the advantage of using @font-face is that it's frees the author from worrying about fallback scenarios; in a world where all browsers support @font-face, the font stack is effectively reduced to a single user-specified family. In the case of fallback for characters not supported by a given font, the set of available weights will be very small in most situations. Given the way the OS/2 usWeightClass value has been abused in the past, there's effectively no broad agreement on how to specify font weights consistently across families at the level David is talking about. The OpenType spec suggests a Thin face should have a weight of 100, yet Adobe will publish it with a usWeightValue of 250, because of the need to hack around the vaguries of GDI behavior. The only thing that will be consistent across families is that a higher weight within a given family will be bolder. Regards, John Daggett
Received on Wednesday, 16 February 2011 02:07:27 UTC