W3C home > Mailing lists > Public > www-style@w3.org > November 2008

RE: CSS3 @font-face / EOT Fonts - new compromise proposal

From: Levantovsky, Vladimir <Vladimir.Levantovsky@MonotypeImaging.com>
Date: Thu, 13 Nov 2008 02:10:34 -0500
Message-ID: <E955AA200CF46842B46F49B0BBB83FF2767D03@wil-email-01.agfamonotype.org>
To: "Brad Kemper" <brkemper.comcast@gmail.com>
Cc: Håkon Wium Lie <howcome@opera.com>, "Dave Singer" <singer@apple.com>, <robert@ocallahan.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, "Ian Hickson" <ian@hixie.ch>, <www-style@w3.org>

Hi Brad, 

> From: Brad Kemper [mailto:brkemper.comcast@gmail.com] 
> Sent: Wednesday, November 12, 2008 11:37 AM
> 
> On Nov 12, 2008, at 7:13 AM, Levantovsky, Vladimir wrote:
> 
> > One part of the compromise solution is using access control 
> instead of 
> > the root strings;
> 
> I like the idea of using access control to relax the "same origin"  
> restrictions, so that I can link to a font from any of the 
> style sheets on my site, not just the ones that happen to 
> reside on the same server. In this case, I would be 
> determining which servers were part of my site, and this 
> would not be written into the font itself. I do not want to 
> have to recompile or rewrap or re-compress the font every 
> time I add a new server or contract with another company to 
> serve some of my content (or their own content that has been 
> customized for my company).
> 

Yes, I agree that access control gives more flexibility to web developer, even though it does weaken a level of font protection to some extent. I think I could live with it given that the font data is still protected by reasonably strong obfuscation mechanism, and I believe that the proposed 'obfuscation-though-font-specific-compression' would be an ideal solution - it would provide both the sufficient level of protection and the high efficiency of font compression.

> In such a scenario, I think that a single bit on the font 
> would be insufficient to communicate licensing rights. I 
> would really need to know the following:
> 
> --Am I restricted from using the font on the Web at all?
> 
> --Can I use it only with a single server?
> 
> --Can I use it with all servers owned and/or operated by my company?
> 
> --Can I use it with all servers (or sub-domains of servers) 
> which do business with my company, that are closely 
> associated with my site, for which I have provided a custom 
> style sheet to aid in it having a similar look and feel?
> 
> I personally would only use fonts that allowed the last 
> option above, but I could see different foundries choosing 
> one of the four options, and letting the market determine if 
> their choice was acceptable enough to enough people.
> 

Fonts can only communicate embedding restrictions used by applications (no embedding, "preview and print", editable, installable). Everything else will depend on the license you get when you buy a font. The license for the font isn't set in stone - when you purchase a font you can specify whether you want the font for personal, internal business or commercial use, how many "seats" (i.e. computers, workstations, servers) you need, what embedding level you need, etc.

For example, when you buy a retail "personal or internal business use license" from Monotype Imaging:
- You will have the rights to install the font on up to five different workstations (servers). 
- You can add multi-user option to it, if needed (up to 20, up to 100, ... up to unlimited).
- You can specify the embedding level you need. By default, it is set to "preview and print", which means you can share the documents you created but the recipient of the documents will not be able to edit them using embedded fonts. In web terms, you can create web pages that use fonts to display static content, but not dynamic. If needed, you can upgrade to editable embedding (e.g. for websites that use dynamic content or have user input fields).

However, there is no limit on how many documents or web pages you can use a font for - once you bought a font, it is yours forever (unless, later on, you decide you need to add more servers, and then you would just pay the incremental price for additional servers).

> On the other hand, how would they communicate this? By 
> selling me all new "web-enabled" versions of the fonts I 
> already paid for? I would resist such a proposal, but 
> honestly, in the end I would probably bite the bullet and 
> purchase them again if it were just a couple of fonts and it 
> wasn't too expensive (type foundries, begin your drooling, 
> over the possibility of extra cash). No one would like that 
> much though.
> 

I can't speak for all foundries, but we are in the business of making our customers happy (so that they come back for more ;-). Our current license does not allow the use of fonts on the web. If we decide to modify the license to allow such use - I expect that all current licensees will get the same rights without any extra charges (provided that the web use is compliant with their original license conditions).

> BTW, once you are no longer relying on the browser to do your 
> enforcement, you could still add watermarking to your 
> compression scheme, in order to track down patent offenders. 
> The UA doesn't need to pay attention to the watermark, but 
> you could build a search engine to monitor watermarked fonts.
> 

I guess it's possible, although I am not sure how.

> > the second part is font data compression that can also serve as 
> > obfuscated font format. I believe we are in agreement that serving 
> > compressed fonts on the web (and, thus, reducing bandwidth 
> and storage 
> > requirements) would be equally beneficial when using both 
> commercial 
> > and free fonts.
> 
> I don't think there is conceptually anything wrong with the 
> idea of compressing the fonts beyond what is available via 
> gzip. However, you also want it to be something that a 
> browser can do and a desktop application can't, correct? This 
> is where you run into a problem.  
> There are other programs besides browsers that use the 
> rendering engines of FireFox and Safari (gecko and webkit). 
> This includes not only newsreaders and e-mail clients, but 
> (with the advent of Google Docs and Google Gears), also 
> includes word processors, spreadsheets, and presentation 
> programs. As time goes on, we may see more and more of our 
> non-Web-related desktop tasks use the rendering engines from 
> Web browsers. Would you disallow them from using commercial 
> fonts linked via style sheets? I don't think you would need 
> to if the access control restrictions were in place, and if 
> fonts pulled from the Web could not be simply dragged from a 
> "temporary objects" folder into the permanent "fonts" folder 
> of the OS.
> 

It is indeed very interesting perspective and I agree with you - I don't see any problem here. Thinking out loud - I would consider any such use to be legitimate, if its implemented according to W3C Recommendation. I see no need to disallow style sheets link to any fonts - either local or linked from a remote server (assuming that they are properly licensed). Local fonts are stored in the raw format anyway, and the fonts from a remote server would be downloaded and decompressed by UA, and made available for temporary use (e.g. while you are using Google Docs). I don't see any problem with it.

Best regards,
Vlad
Received on Thursday, 13 November 2008 07:10:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:17 GMT