- From: John Daggett <jdaggett@mozilla.com>
- Date: Wed, 21 Jan 2009 02:13:53 -0800 (PST)
- To: Thomas Phinney <thomas.phinney@gmail.com>
- Cc: www-style@w3.org, Zack Weinberg <zweinberg@mozilla.com>
>> As for the second issue, what the name within local() means, it will >> vary with format but I think we need to define this clearly for >> TrueType/OpenType fonts to assure cross-platform consistency. > > That is a *huge* issue. There are a lot of different "name" fields in a > font, and which one is meant is quite unclear. I've seen engineers > forced to invent completely arbitrary interpretations just to do > *something*. I think it's a most unsatisfactory and troubling situation. Thomas, are you saying this is an issue of (1) how to use a system API to look up a particular font face or (2) which name record to match within a TrueType/OpenType font when using local() within an @font-face rule? Or are you thinking of how font family name matching works, something that's independent of how local() functions? The sentence in the spec is now "For TrueType and OpenType fonts, the full font name as defined in the font name table is used to reference a given face." By that I mean it should match the name record in the name table with name ID = 4. Modulo name localization issues, I think that's fairly clear. How to match this using system API's on various platforms may not be. If you're thinking about font family name matching, I would agree that's a big issue in a 4-faces-per-family Windows GDI world. That would drive any engineer to despair. But it's a "yes we can" world now, no time for despair... Cheers, John Daggett Mozilla Japan
Received on Wednesday, 21 January 2009 10:14:35 UTC