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

Hi Boris, 

> -----Original Message-----
> From: www-style-request@w3.org 
> [mailto:www-style-request@w3.org] On Behalf Of Boris Zbarsky
> Sent: Monday, November 10, 2008 11:54 AM
> To: Brad Kemper
> Cc: www-style@w3.org
> Subject: Re: CSS3 @font-face / EOT Fonts - new compromise proposal
> 
> 
> Brad Kemper wrote:
> >> 1) by default, font resources linked with @font-face will be 
> >> protected by access control same origin restrictions
> ...
> > Is there any way for the author to turn that off? Or to 
> specify a list 
> > of sites that all belong to the same licensee or are used 
> by the same 
> > licensee?
> 
> Yes, see the Access Control draft.
> 
> > For instance, if my main site is www.xyz.com 
> <http://www.xyz.com>, can 
> > I still use it with 123.xzy.com, xyz.com, and 
> secure.xyz.com, so that 
> > I don't have to have 4 different fonts or have the same font load 4 
> > times without caching between these domains?
> 
> Yes, if you set up the server that serves up the font correctly.
> 
> > And what about if my "site" (in the larger sense) is using pages on 
> > other servers that are not part of my domain? Often these 
> outsourced 
> > sections of my site allow me to have a custom CSS file for 
> integration 
> > of the look and feel. How can I get them to use my font, without 
> > actually being able to serve it from their servers?
> 
> See the Access Control draft.  Basically, you just have to 
> send the appropriate Allow HTTP headers with your font.  How 
> those headers get there is up to your HTTP server, of course. 
>  If you want to use an XML file for configuring this, go for 
> it.  Your HTTP server just needs to support that syntax.
> 

Thank you for clarifying this.

> > But I don't think it would offer any protection. Do the operating 
> > systems need to be updated so that they can read compressed 
> versions 
> > of the fonts?
> 
> Vladimir's proposal is that the UA would do the 
> decompression, then give the decompressed data to the OS.  In 
> fact, it depends on it being a patent violation for the OS.
> 
> Except, of course, for an OS that's developed by the 
> patent-holder, of course.  I find this a cause for some concern.
> 

The patent holder is Monotype Imaging and we do not develop OSs. As you
pointed out, UA will do the decompression and then just handle the data
to OS. I really don't see any need for OS to implement its own
decompressor unless the same functionality (i.e. font
compression/decompression) is going to be offered for other applications
running on that OS. And, if this is ever the case, they are always
welcome to get your own license.

Best regards,
Vladimir

> > But if not, then the AU decompresses the font and then 
> what? Saves it 
> > to a cache folder in a form that the OS can understand?
> 
> That depends on the APIs the OS exposes.  Can you pass in TTF 
> data directly as a memory buffer?
> 
> On many operating systems (Windows not in that set, but most Unices in
> it) you can create the file, open it, pass someone the file 
> handle, and then unlink the file.  As long as the file handle 
> consumer doesn't close it, they and no one else can get at 
> the data.  There's a race here, of course, between creation 
> and unlinking, but heck: the data is on disk _somewhere_ if 
> you really want to get it.  That's true even with the memory 
> buffer, given paging.
> 
> But all that is not the threat level we're trying to address here.
> 
> -Boris
> 
>

Received on Monday, 10 November 2008 18:12:05 UTC