RE: New work on fonts at W3C

On Tuesday, June 23, 2009 12:34 PM Chris Wilson wrote:
> 
> Håkon Wium Lie [mailto:howcome@opera.com] wrote:
> >You could e.g. start by responding to this proposal:
> >
> >  http://lists.w3.org/Archives/Public/www-style/2008Nov/0412.html
> 
> 1. I don't think CORS is a good application here, as it seems much more
> destructive to workflow than generating EOT files.
> 
> 2. yes, I think this (lightweight obfuscation/compression scheme) is a
> good idea.  That's essentially what EOT does, and checks the embedding
> bit to see if it can generate embeddings for the font.  If the concern
> is field of use of MTX, then I'd like to see that defined, and then we
> can ask Monotype to remove that restriction.
> 

I believe that the issue related to field of use restriction has already been resolved to mutual satisfaction:
http://lists.w3.org/Archives/Public/www-style/2009Jun/0228.html
http://lists.w3.org/Archives/Public/www-style/2009Jun/0321.html

We have now two proposals on the table: one from Ascender that addresses the issue of lightweight obfuscation mechanism, and Monotype MTX compression technology. These two components seem to be the perfect fit for the compromise solution proposed by Håkon: "lightweight obfuscation / targeted compression scheme". The lightweight obfuscation and compression can be easily implemented in a browser (Monotype could probably offer a helping hand there) and can also be easily integrated into an existing workflow where the original fonts (whether commercial or freeware) can be processed by a simple utility with no additional input from site owner/author. 

Pending additional discussions on the same-origin restriction and CORS, I can see that this compromise solution will address the needs and concerns of all web users:
- simple to use by web authors
- minimizes bandwidth use for fonts - reducing the usage site owners pay for, and improving the experience of billions of users worldwide.
- satisfies the needs of font vendors (files hosted by a server cannot be directly installed as system fonts);
- implementable by anyone, including open source browsers and tools.


> 3. (linking to "standard" TTF/OTF files)  As previously indicated, I
> don't see any way to make this palatable (without requiring additional
> bits in the TTF/OTF that say this usage is allowed, that would not be
> set in most commercial fonts - e.g. "does not work with any current
> fonts, freeware fonts would have to be updated.")
> 

I absolutely agree. 
I also would like to say that I do not see any reasonable way to make it work even if we take into account the font renaming scheme that John Daggett proposed, and for the following reasons:
- renaming of the fonts to something like "This font is used by XYZ Corp. for their abc.com website" (or anything else to that matter) requires manual input, regardless of the tools you use. Considering the likely scenario that a website may use more than one downloadable font at the same time (and possibly from different vendors) would make this renaming scheme rather messy and would require authors to keep track of original name / nickname mapping;
- requiring this to be done by our customers will sure turn some of them (many) away, and font vendors do not want this to happen. Also, I cannot even imagine font vendors asking their customers to modify license description field;
- the solution that puts commercial font vendors in unfair position isn't really a solution;
- the solution seems to be more like a hack is not a solution - I suspect it may not work consistently (the example presented by John doesn't work with Google Chrome) and may cause some unpredictable complications on different platforms when OS rendering engine is used by a browser.


> -Chris

Received on Tuesday, 23 June 2009 18:44:48 UTC