- From: Michael Jansson <mjan@em2-solutions.com>
- Date: Wed, 04 Mar 2009 09:54:08 +0100
- 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 UTC