Re: New work on fonts at W3C

On Jun 18, 2009, at 8:05 PM, John Daggett wrote:

>>> 2) Change the contents of the license record to say "This font
>>> licensed to xxx by yyy for use on site zzz.  All other use
>>> restricted and governed by the terms below.  For more information on
>>> this excellent font please visit www.example.com/fantasticfont."
>>>
>>> [...]
>> These sound like really great ideas. I wonder if one of the fields
>> (such as the license record) could contain a machine-readable list of
>> sites that the font was licensed for, and if that list could be used
>> for CORS (for an HTTP server serving the font to read and include in
>> the header, or for the browser to read directly as though it was a
>> header).
>
> Things like machine-readable lists of domains are equivalent to a root
> string solution, like EOT, and suffer the same problems: moving the
> font file around between different servers (e.g. stage to production)
> requires constant updating of the font data, is difficult to work with
> locally (e.g. drive/path inclusions in EOT spec(!)), and breaks down
> completely when used with caching servers (e.g. Akamai).

Doesn't CORS have to deal with all that anyway? At some point, in  
order to make CORS versions of root strings work (as per the current  
working draft[2]), someone has to enter a list of "source origin  
strings" somewhere for each resource you want to restrict, and then  
the server needs to look at that list in order to know how to set the  
HTTP headers. I'm just suggesting that the server could look at the  
list in the font itself in order to automatically set the list that  
CORS uses for that font.

Thus, an existing field in a widely used font format could provide  
information that would be useful in providing information that an  
implementation of an upcoming resource sharing standard would need  
anyway.



2. http://www.w3.org/TR/access-control/#access-control-allow-origin-response-hea

Received on Friday, 19 June 2009 16:16:54 UTC