RE: New work on fonts at W3C

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

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?


> -----Original Message-----
> From: [] On Behalf Of
> Aryeh Gregor
> Sent: Wednesday, June 24, 2009 9:35 AM
> To: Levantovsky, Vladimir
> Cc: Brad Kemper; Jonathan Kew;
> Subject: Re: New work on fonts at W3C
> On Wed, Jun 24, 2009 at 12:33 AM, Levantovsky,
> Vladimir<> wrote:
> > 3) However, the use of renamed fonts will affect normal @font-face
> > workflow. When you use a real font name, the UA would usually look if
> a
> > font is available, and only if not found, it would download a
> resource
> > specified by @font-face-src. Renaming fonts will force UA to always
> > download a font, even if identical font is installed.
> The CSS3 @font-face spec contains the following example:
> @font-face {
>   font-family: Gentium;
>   src: local(Gentium), url(/fonts/Gentium.ttf);
> }

> The standard says that this would use the locally-installed font if
> available, otherwise the font from the URL.  So the rule in our case
> might look like:
> @font-face {
>   font-family: "High-Quality Font";
>   src: local(High-Quality Font),
> format("opentype");
> }
> In fact, the font filename and the name embedded in the font file
> aren't used at all in CSS, AFAICT.  The standard gives examples like
> this as well:
> @font-face {
>   font-family: Japanese;
>   src: local(HiraKakuPro-W3), local(Meiryo), local(IPAPGothic);
> }
> > Typically, web authors use more than one font family for their
> content
> > (where each font family may include multiple font files representing
> > different styles and weights) - authors would have to manually keep
> > track of all the original font files and those that are renamed.
> The mangled font name could contain the original font's name, so that
> authors can keep easy track, in addition to the license warning (as I
> illustrated above).  It will still be impossible for users to use the
> font without realizing they're violating the license terms.  The only
> disadvantage to authors that I can see is that the names would be long
> and look ugly, but I think that's really a very minor detail.  You
> could even have your program auto-generate the @font-face rules, if
> the author gives the URL to the folder he's putting the font files in.
> > In
> > addition, I suspect an author's ability to use other CSS properties
> like
> > font-style, font-weight, etc. may be affected by font renaming.
> Why do you suspect that?  From reading the standard, it seems like
> you'd specify different font styles and weights just as for any
> @font-face.  @font-face completely ignores the filename and any
> embedded naming metadata, AFAICT, so to the author the only difference
> should be what URL they have to put in the src() rule: that's the only
> place it makes a difference to @font-face.  I don't think this would
> be a noticeable additional burden to web page authors, as compared to
> EOT.

Received on Wednesday, 24 June 2009 14:43:09 UTC