Re: [css3-webfonts] Proposal-in-progress for cross site font sharing [was "Downloaded fonts should not..."]

On Apr 17, 2008, at 1:05 PM, Dave Crossland wrote:

> On 17/04/2008, Brad Kemper <brkemper@comcast.net> wrote:
>>
>>>> Maybe your suggestion would work though if the headers
>>>> contained something like an MD5 number that was verified.
>>
>>> There you go. Now you're thinking along similar lines to what I
>>> was thinking when I mentioned encryption.
>>> The problem is, where would these headers go? Would this need
>>> a new font format? Could they be applied to existing formats?
>>
>> Short answers: "TBD", "hopefully not", and "hopefully so".
>
> My answers:
>
> 1. http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.15
>
> 2. OpenType is over 10 years old and is showing it, and we do need
> support for new font formats like SIL Graphite to become more
> widespread.
>
> 3. HTTP works okay for most any data format :-)

It seems promising, but that's at the server level, right? Is there a  
way to trigger the header at the file level, so the header would be  
per-font, without requiring a server add-on or new font format?

The thing with fonts is that most people will want to use the ones  
they have or that are easily available. And the at-rule already works  
with existing font formats. So ideally that could be leveraged. I  
suppose that if there was a way to convert existing formats to a new  
one that somehow generated its own HTTP header (or instructed the  
server to do so, the way an .asp page can) that would be a good step  
(provided the implementations could easily add in new formats). Of  
course, as you might have guessed, I don't really know that much about  
how such things work. Maybe it is easier than what I imagine.

I was hoping for a solution that did not involve new font formats. I  
remember the PIA of trying to convert my existing fonts into EOT  
files, using the only piece of software ever available AFAIK to do so  
(which only ran on PC). I didn't like it.


>
>
>> I was initially imagining that information to be in a new type of  
>> HTTP
>> header, but that might not be workable (I'm not sure) ... if there is
>> already an HTTP header with file meta-data that precedes a
>> download, then it could be shoe-horned into that.
>
> :-)
>
> -- 
> Regards,
> Dave

Received on Friday, 18 April 2008 04:33:25 UTC