- From: Michael Jansson <mjan@em2-solutions.com>
- Date: Wed, 04 Mar 2009 10:54:06 +0100
- To: Adam Twardoch <list.adam@twardoch.com>
- CC: Thomas Phinney <tphinney@cal.berkeley.edu>, Michael Day <mikeday@yeslogic.com>, John Daggett <jdaggett@mozilla.com>, www-style <www-style@w3.org>, HÃ¥kon Wium Lie <howcome@opera.com>
- Message-ID: <49AE4FBE.1040407@em2-solutions.com>
Hi Adam, Adam Twardoch wrote: >> Thomas Phinney wrote: >> >>> 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. >>> > > This discussion of course mostly applies to "client fonts" i.e. fonts > installed on the user's client. Fortunately enough, the web fonts > mechanism provides a complete abstraction from the actual font naming > contained in the fonts, which I think it quite wonderful. I'd like to > remind everyone that with "server fonts" aka "web fonts", CSS provides, > essentially, a font _installation_ system that sets up a completely new > naming scheme independent of the font naming contained in the font > files. For example: > > @font-face { > font-family: "Twardoch Body"; > font-weight: normal; > src: url("http://www.twardoch.com/fonts/garamond.ttf") > } > > @font-face { > font-family: "Twardoch Body"; > font-weight: bold; > src: url("http://www.twardoch.com/fonts/arialblack.ttf") > } > > body { > font-family: "Twardoch Body"; > } > > <html><body> > <p>This is Garamond and <strong>this is Arial Black</strong>.</p> > </body></html> > > Which seems to at least partially solve the problem, no? > > BTW, I just looked at a test page I made and it seems that Safari > supports both http:// and file:// URL links to web fonts while Firefox > does not support file:// at all. > > Adam > > This is indeed quite wonderful. I thought I mention a few caveat here. Browser needs to explicitly manage the name of installed web fonts. It's not enough to use suitable system APIs to install the web font without taking the appropriate actions to rename the font to match the font-family descriptor. The family name may clash with the name of a system font, and may even be localized and thus be different from the name used with the web authors locale (e.g. a Japanese family name in kana or roman, depending on if you are on a Japanese system or not). In any case, the font needs to be renamed to ensure that it is being used when it should be used. Also, there are simple enough system APIs for supporting EOT fonts on Windows. It's a one-liner to support there, so I would suggest that anyone supporting web fonts on Windows consider using those APIs: http://msdn.microsoft.com/en-us/library/dd144828(VS.85).aspx One more issue; browser *should* check the embedding permission before using web fonts. Font vendors may not approve to having their fonts re-distributed with documents (including web pages). There is an easy enough API for checking this on Windows: http://msdn.microsoft.com/en-us/library/dd145154(VS.85).aspx On other platforms, check the platform documentation.
Received on Wednesday, 4 March 2009 09:55:31 UTC