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

Re: New work on fonts at W3C

From: Christopher Slye <cslye@adobe.com>
Date: Wed, 24 Jun 2009 11:59:29 -0700
Message-ID: <96AEF709-1D09-4D1C-9B96-9F2D5E15CE25@adobe.com>
To: www-style@w3.org
My personal opinion -- having not talked to the lawyers and engineers,  
the opinions of whom are of substantial value with a subject like this  
-- is that the font-name-change idea is a nonstarter. Why, you will  
ask? Well, to be candid it simply strikes me as hacky and inelegant,  
but more substantially, it is a distraction from discussion of much  
more mature, comprehensive proposals, namely Ascender's, or even the  
old EOT proposal. (Is the latter really dead or not?)

A proper solution will, IMO, employ obfuscation, subsetting and  
compression. And although I think the details are still quite murky,  
the ideas for license info embedding and access control are worthwhile  
and can best be accomplished with a new font wrapper. (I would call it  
a format, but I don't want to set anyone off. We're really talking  
about a file that essentially packages an existing font file.)

Like Vlad, I would prefer a more focused discussion on the merits of  
Ascender's proposal. What would really be nice is if the Fonts Working  
Group could get rolling with a constructive investigation. John D. has  
said he is open to consider these things, so I would like to see  
Mozilla and other browser developers join the font foundries and  
everyone else there with an eye toward a concrete recommendation. It  
really does seem to me that many previously-contentious issues (DRM,  
IP) have been addressed.

Just to be clear: I think the free-form discussion that's been going  
on here is interesting, important and certainly useful for exploring  
new and different approaches. With that said, we do, at some point,  
have to focus on something, and like I said, the font-renaming  
approach seems second-tier at best.


On Jun 24, 2009, at 7:42 AM, Levantovsky, Vladimir wrote:

> I think we constantly get side-tracked by EOT (and WEFT), although  
> the proposal we have on the table has evolved considerably since  
> then. The options that we are considering are same-origin  
> restriction and a font wrapper that implements simple-obfuscation  
> and targeted font compression (as outlined by http://lists.w3.org/Archives/Public/www-style/2008Nov/0412.html) 
> .
> The proposed solution we have on the table would provide a universal  
> support for use of font linking in all browsers, and would make this  
> completely transparent for web authors. Authors will no longer be in  
> a position where they need to do something special for different  
> browsers, and both free and commercial  fonts would be supported  
> equally well. The only step web authors would have to accommodate is  
> to run a tool that compresses a font file and puts it in a wrapper a  
> browsers can handle. Using the example you presented, a single CSS  
> module would be needed to specify a custom font:
> @font-face {
>  font-family: Gentium;
>  src: local(Gentium), url(http://my_domain/fonts/ 
> <wrapped_Gentium_font_file>); }
> This proposed solution brings all web users together:
> - web authors will have a simple workflow solution that works  
> consistently in all browsers, and with any font they chose;
> - web pages will load faster which will benefit both authors and end- 
> users;
> - font vendors will open their font libraries to web authors;
> - the web will fulfill the promise of high-quality typography, and,  
> the last but not least,
> - all this can be done with a rather simple piece of code added to a  
> browser, with free for all, unrestricted patent license (speaking  
> about compression - the lion share of the complexity is in the  
> compressor itself, the decompressor that would be supported by a  
> browser is very simple to implement).
> Once unwrapped, a font will then be processed exactly the same way  
> WebKit and Firefox handle raw fonts today - the proposed solution is  
> not a substitute for what is already implemented, but a simple  
> extension.
> So, maybe instead of trying to come up with a way to make authors  
> jump through the hoops *all the time* to keep the status quo, we  
> should get together as a community and do what is best for the  
> community. A simple one-time change in a browser code and a new tool  
> for web authors is all it takes to "lead the Web to its full  
> potential". Chris Wilson has clearly indicated that IE team is  
> willing to explore, develop and implement new web font solution,  
> will other browser vendors join this initiative?
Received on Wednesday, 24 June 2009 19:00:24 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:27 UTC