W3C home > Mailing lists > Public > www-font@w3.org > April to June 2010

Re: WebFonts WG discussions

From: Matt Colyer <matt@typekit.com>
Date: Tue, 4 May 2010 09:34:40 -0700
Message-ID: <g2h9fdb0b521005040934waa726e97mc557a6b28c9ea776@mail.gmail.com>
To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@monotypeimaging.com>
Cc: Erik van Blokland <erik@letterror.com>, "www-font@w3.org" <www-font@w3.org>
On Tue, May 4, 2010 at 7:17 AM, Levantovsky, Vladimir <
Vladimir.Levantovsky@monotypeimaging.com> wrote:

>  Hi Erik,
>
>
>
> A short answer is – it would not affect this ability at all.
>
> The long answer: the proposed checksum will be calculated based on the WOFF
> data including Header, Table Directory and extended and private metadata
> fields, and will be set to equal the difference between the calculated value
> and the checkSumAdjustment of the original font encapsulated in the WOFF as
> a payload. In order for UA to verify the integrity of WOFF data it will need
> to calculate the checksum for WOFF data and match its value against the
> ‘checkSumAdjustment’ field of downloaded ‘head’ table (this is the only
> table UA would have to download, but it would have to do it anyway, and the
> table size is small). Once UA downloaded the ‘head’ table and verified the
> integrity of WOFF data, the UA can proceed and download any desired
> selection of specific tables, the same way that you could do it now.
>

I am interested to hear why a checksum is considered necessary/beneficial in
WOFF. Since fonts will be served over HTTP which itself is served over TCP,
the data is guaranteed not to be corrupted through transmission.

-Matt


  *From:* Erik van Blokland [mailto:letterror@gmail.com] *On Behalf Of *Erik
> van Blokland
> *Sent:* Tuesday, May 04, 2010 4:01 AM
> *To:* Levantovsky, Vladimir
> *Cc:* www-font@w3.org
> *Subject:* Re: WebFonts WG discussions
>
>
>
> Vlad,
>
>
>
> On 3 mei 2010, at 17:40, Levantovsky, Vladimir wrote:
>
>
>
>  This approach would allow user agents to verify the integrity of WOFF
> data fields and match it against the font ‘checkSumAdjustment’ encoded as
> part of the font ‘head’ table [3]. The suggested approach would **not**
> require decompressing the whole font to calculate checksum, and  would
> preserve the ability of UA to selectively decompress font tables to only
> retrieve portions of font data as needed.
>
>
>
> How would this checksum affect the ability of the UA to download only
> specific tables?
>
>
>
> Erik
>
Received on Wednesday, 5 May 2010 13:12:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:34 UTC