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

Re: [CSSWG] Minutes and Resolutions Tokyo F2F Fri: Fonts

From: Håkon Wium Lie <howcome@opera.com>
Date: Wed, 25 Mar 2009 16:06:32 +0100
Message-ID: <18890.18552.994745.218434@opera.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: www-style@w3.org
fantasai wrote:

 > Summary:

   ....

I'd like to add one item to the summary:

 - a non-normative description of font APIs to use on major platforms
   will be added to the Font draft. In particular, the draft will
   describe how to find the "unique font face name" to be used within
   local().

The longish discussion on this item is here:

 > type of local() name
 > --------------------
 > 
 >     jdaggett: there's no ideal name that works on all platforms
 >     jdaggett: on the Mac you'd use the postscript name
 >     jdaggett: all fonts on a mac have a postscropt name, either real or
 >               synthesized
 >     jdaggett: what I have now is that all platforms allow lookup via the
 >               full name
 >     howcome: you want to support having style in the name of the family
 >     jdaggett: the name you have here uniquely describes the font within a family
 >     discussion of whether this is portable across platforms
 >     [shouting, minute taker gets lost]
 >     [excited shouting, for those wondering]
 >     <ChrisL> fullname is family plus style except for the regular, where style
 >              is omitted
 >     jdaggett: postscript name doesn't necessarily match the name in the style
 >     <ChrisL> so, you would need to specify it twice, fullname and postscript
 >              name?
 >     <ChrisL> (cl hears both yes and no)
 >     jdaggett: there are OTF fonts where the full name under Windows is the
 >               postscript name
 >     jdaggett: but on the Mac it is the normal full name
 >     <ChrisL> so the postscriptname should go first, followed by the fullname
 >              (if different to postscript name)
 >     <ChrisL> _DSC2185
 >     jdaggett: yes
 >     jdaggett: authors would use local() because they can control individual
 >               faces and you cannot do that with font-family
 >     SG: font-family only allows the generic family, not a specific face
 >     howcome: why not use the font filename?
 >     jdaggett: with this nomenclature you have the hope of matching cross
 >               platform, with file names it fails
 >     Steve: the API is that you give the system a name and use the first it
 >            returns
 >     howcome: I'm afraid different systems will react differently
 >     jdaggett: with unicode-range and local() you can create interesting
 >               combinations that will work across platforms
 >     howcome: my experience is different
 >     jdaggett: that is because fonts are not cross platform
 >     jdaggett: this is inherently platform specific
 >     howcome: I think that's why we shouldn't do it
 >     Anne: font-family is also platform specific
 >     howcome: we should not expand on that
 >     [rehashing of unicode-range and other arguments]
 >     howcome: does local() and font-family work the same?
 >     jdaggett: no, but in some cases it will
 >     Steve: anything which varies on one of the descriptors, must be specified
 >            by @font face not font-family
 >     Chris: we don't want people to use font-family: "Helvetica Bold Italic"
 >     * anne needs a break
 >     howcome: I'm ok with this as long as it is interoperable
 >     <ChrisL> I wonder if a font-size descriptor plus src would let us get at
 >              optical variants
 >     Anne: the spec can give advice
 >     jdaggett: of course
 >     Steve: I don't want API descriptions in the spec
 >     Anne: if that's the reality it seems better to specify reality
 >     Anne: e.g. ARIA does that too
 >     Steve: as long as it is clear that it is one way of doing it

Cheers,

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Wednesday, 25 March 2009 15:10:13 GMT

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