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

Re: [css3-fonts] font descriptor default values

From: Michael Jansson <mjan@em2-solutions.com>
Date: Wed, 04 Mar 2009 09:54:08 +0100
Message-ID: <49AE41B0.9000502@em2-solutions.com>
To: Michael Day <mikeday@yeslogic.com>
CC: Thomas Phinney <tphinney@cal.berkeley.edu>, John Daggett <jdaggett@mozilla.com>, www-style <www-style@w3.org>
Michael Day wrote:
> Hi Thomas,
>
>> In OpenType and TrueType, there are a variety of name fields
>> available, and font developers can express the "real" family grouping
>> just fine alongside the GDI-friendly one. But that's not what gets
>> shown to GDI apps, including browsers AFAIK. Mac OS doesn't have these
>> restrictions, but as long as any major OS API does, there's an issue.
>
> Given that Linux with Fontconfig does not have these restrictions 
> either, it seems that the issue here is one of Windows-specific 
> hackery necessary to compensate for its broken font support, until the 
> platform itself can be improved in future versions.
There are issues on Linux as well, as X Windows/Linux is less mature in 
terms of managing font families than both Quartz/Mac and GDI/Windows. I 
should also mention that there are other issues as well w.r.t. 
supporting different font formats, as well as issues involved in using 
localized face/family names and fallback fonts in language support.

Given that you can actually do the right thing in GDI, and that the 
problems is equally divided between font vendors and application 
writers, I wouldn't expect GDI to change anytime soon.

>
> For example, if a page asks for "900 12px Arial", then arguably the 
> normal weight of "Arial Black" would be a better font face to provide 
> than the bold weight of "Arial". But what kind of naming conventions 
> would be necessary to make this work, given the lack of API cooperation?
> Could font authors and user-agent developers make an arrangement to 
> work around the limitations?
Font vendors still need to make their fonts work in all apps and GDI 
needs to be backward compatible. Further more, the fonts themselves may 
already contain the needed information to select fonts correct. I would 
suggest you wrap your own code to select the right fonts on windows 
instead. Although documentation may suggest otherwise, you probably want 
to do your own font enumeration and then use the face name (not the 
family name) when opening a font in GDI. You will override some of the 
font matching in GDI if you use a name like "Arial Italic" instead of 
just "Arial". To cope with localized face/family names, you would need 
to enumerate fonts and look up the family name with the GetFontData API, 
accessing the 'name' table data directly. Take care when working with 
TTC and TTF/OTF fonts, as the API takes slightly different arguments for 
these two variants of the sfnt format (see SDK) For event more portable 
solution, you should to have the same code (with the equivalent of 
GetFontData for the platform, e.g. fopen on Linux :-) run on all platforms.
>
> It doesn't seem like a good idea to complicate CSS to address an issue 
> currently affecting one platform, and the @font-face solution is not 
> very helpful if it means that the font properties will never be enough 
> by themselves, and authors need to explicitly alias all the fonts they 
> might want to use to ensure that they work as expected.
Indeed. I would prefer to consider misbehaving in browsers as bugs and 
leave the CSS spec as-is. Also, I wouldn't want to tie the CSS spec to 
how fonts are handled on specific platforms or even how specific font 
formats are handled.
>
> Best regards,
>
> Michael
>
Regards,
Em2 Solutions AB
Michael Jansson
Received on Wednesday, 4 March 2009 08:55:28 GMT

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