W3C home > Mailing lists > Public > www-font@w3.org > July to September 2009

Re: Format name proposals

From: Laurence Penney <lorp@lorp.org>
Date: Tue, 18 Aug 2009 22:36:55 +0100
Cc: John Hudson <tiro@tiro.com>, "www-font@w3.org" <www-font@w3.org>
Message-Id: <7082BB15-57F0-4CD9-97CC-44EE74507117@lorp.org>
To: Jonathan Kew <jonathan@jfkew.plus.com>
On 18 Aug 2009, at 22:21, Jonathan Kew wrote:

> On 18 Aug 2009, at 22:00, Laurence Penney wrote:
>>> JH:
>>>> [By the way, since the OT and OFF specs are not formally  
>>>> identical and with no guarantee against them diverging at some  
>>>> stage, I wonder if there is a benefit to the web font format in  
>>>> choosing one of these as the formal definition of the fontdata  
>>>> format?]
>> JK:
>>> I'm not sure there's any real benefit there. WebOTF or WOFF or  
>>> whatever we call it is really a repackaging of sfnt data, and is  
>>> independent of the details of what's inside the sfnt tables. It's  
>>> true that if OpenType and OFF were to diverge, implementers would  
>>> have to choose what to support, but that's equally true for "raw"  
>>> sfnt data as for sfnt-repackaged-in-EOT/EOTL/WOFF/whatever, and  
>>> doesn't directly affect the actual web-repackaging formats.
>> There might also be good reasons for allowing WebOTFs which don't  
>> expand to fully working fonts at all.
>> For example, one might conceive of web pages linking to a web font  
>> that contains only the glyphs required to render that page.  
>> Successive page views on the same site would request only the  
>> additional glyphs needed to render the new page, via a WebOTF that  
>> contained the new glyphs - just a loca and glyf table - which would  
>> be inserted into the correct place in a font being gradually built  
>> up by the browser.
> That sounds like a nightmarishly complex scenario. You don't just  
> need the glyph data (loca + glyf, or CFF). What about metrics and  
> hints -- the "global" stuff as well as the instructions on the  
> individual glyphs? And kerning -- not just between glyphs in such a  
> subset, but also between the older glyphs and the newcomers? And  
> then there are GSUB and GPOS layout tables, with all those lookups  
> that operate in terms of glyph indices; you'd have to constantly  
> readjust those as new glyphs arrive.
> Perhaps someone will design a protocol and format suitable for this  
> kind of use, but WebOTF (or anything that is simply designed as a  
> mechanism to deliver OpenType fonts) isn't the answer.

Glyph indices were intended to be preserved in my sketch above, and  
all the other tables downloaded at the outset. But in any case it was  
not a serious proposal.

Yet, if someone came up with a concept for delivering font data  
cumulatively in compressed sfnt tables, why wouldn't they use a well- 
known delivery mechanism for that?

- L
Received on Tuesday, 18 August 2009 21:37:32 UTC

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