W3C home > Mailing lists > Public > www-style@w3.org > January 2009

Re: [css3-fonts] new editor's draft

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>
Message-ID: <12469225.6255311232532833945.JavaMail.root@cm-mail01.mozilla.org>

>> 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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:15 GMT