Re: [WOFF] Checksums, IDs, and Local Cacheing

Hi Doug,

> I had a brief conversation about WOFF with someone (whose name is
> lost in the mists of time) at Web Directions South in Sydney a
> couple weeks ago, and he wondered if there was a way to cache Web
> fonts locally, but still identify their ranges in case of glyph
> subsetting.

Although you list WOFF-specific elements, this is really a question related to the @font-face mechanism, not WOFF itself.  It could apply just as well to OpenType/TrueType or EOT fonts as well.  

> A user who had visited that site before, or who had visited a site
> using that same font, would have it in their cache, saving them from
> downloading it yet again, and saving the bandwidth for the server.

Like all web resources, fonts are cached, the second time around they will be pulled from the local browser cache or a cache of activated fonts keyed on the web font URL (assuming meta-tags or server HTTP header settings don't effectively disable this caching).

It seems like what you're asking for is a way of caching fonts by a mechanism other than the URL.  There are security reasons this isn't such a great idea; if you provide a way that the fonts of one site can end up on the content of another site, you effectively enable malicious content to be injected into another page.  It's also difficult to imagine a caching mechanism that would be foolproof, it would be awfully easy to create two fonts that would be different but have the same key. 

CC'ing www-style on the response.

John Daggett
Mozilla Japan

----- Original Message -----
From: "Doug Schepers" <schepers@w3.org>
To: "www-font" <www-font@w3.org>
Sent: Friday, October 23, 2009 9:22:45 PM GMT -08:00 US/Canada Pacific
Subject: [WOFF] Checksums, IDs, and Local Cacheing

Hi, Folks-

I see that there are a few different "font identifier" mechanisms in WOFF:

1) The font name

2) The majorVersion and minorVersion of the font

3) "sfnt-based fonts store a checksum for each table in the table 
directory,"

4) "and an overall checksum for the entire font in the head table"

5) "uniqueid element" "A unique identifier string for the font."

#1, #2, #4, and #5 apply to the whole font, while #3 is per table.

I had a brief conversation about WOFF with someone (whose name is lost 
in the mists of time) at Web Directions South in Sydney a couple weeks 
ago, and he wondered if there was a way to cache Web fonts locally, but 
still identify their ranges in case of glyph subsetting.

This also struck me as particularly helpful for places with poor or 
expensive bandwidth, which sometimes happen to coincide with locales 
where there are frequently very few available fonts for the local 
language, so being able to identify a particular font as being cached 
locally is of increased value (that is, the chance that a given font is 
already cached is higher, and the cost of downloading it again is 
relatively greater).  It would be great if a given font wouldn't have to 
be downloaded multiple times.

Obviously, the name of the font (even with consideration for the major 
and minor versions) is not a good identifier... there are many duplicate 
names for different font families (how many are named "LED", for 
example) so you can't be sure it's the same font, and particular glyphs 
may be changed by the font user so you can't be sure the font doesn't 
have some specialized purpose from the original, tables may have been 
stripped or subsetted, etc.

However, the checksum, in combination with the font name, might be a 
good way to uniquely identify a font, such that a designer could 
indicate it in their CSS @font-face rule:

   @font-face {
     font-family: "Obscure Serif Bold";
     src: url("http://www.example.com/resources/ObscureSeBd.woff");
     checksum: "8675309";
   }

A user who had visited that site before, or who had visited a site using 
that same font, would have it in their cache, saving them from 
downloading it yet again, and saving the bandwidth for the server.

I think this is more an issue for CSS with @font-face, but I thought I'd 
bring it up here for consideration first.  I suspect there may be issues 
with how cacheing works, or other problems I haven't foreseen, but I 
thought it was worth asking.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Sunday, 25 October 2009 05:42:27 UTC