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 10:54:06 +0100
Message-ID: <49AE4FBE.1040407@em2-solutions.com>
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>
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 GMT

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