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

Re: Agenda, action items and suggested WOFF changes

From: John Hudson <tiro@tiro.com>
Date: Tue, 18 May 2010 11:38:09 -0700
Message-ID: <4BF2DE91.3030507@tiro.com>
To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@MonotypeImaging.com>
CC: rfink@readableweb.com, 'Thomas Phinney' <tphinney@cal.berkeley.edu>, 'John Daggett' <jdaggett@mozilla.com>, 'Chris Lilley' <chris@w3.org>, public-webfonts-wg@w3.org, www-font@w3.org
Vlad wrote:

> I believe at the last conference call we all come to an agreement that WOFF is not a font, it is a container file format that encapsulates a font. WOFF itself doesn't have embedding permissions defined, and the process of downloading and unpacking a WOFF file has nothing to do with original font embedding permissions. As soon as a font contained in WOFF file is unpacked, we are outside the WOFF realm and into an original font domain, where embedding permissions may have a role depending on the use case (as John D. and Håkon pointed out).
> But the points raised by Håkon and John Daggett clearly pointed out that the blanket statement is not appropriate - the treatment of these bits depends on a use case. Displaying the content as presented would not require paying attention to embedding permissions, but it may not be appropriate for UA to ignore them in other use cases, and should be left up to the UA as Håkon suggested.

I think we're differently interpreting the import of what Håkon and John 
D wrote. As you say here, at the stage where the embedding bits become 
important again, we're no longer dealing with a WOFF file: we're dealing 
with an unpacked font being embedded into a document.

What I'm proposing is that we might be able to make it clear that the UA 
legitimately ignores embedding bits when downloading and opening the 
WOFF container. What it does with the font after it has been unpacked is 
a different matter.

> No, I don't think so. But I do believe that the ambiguities created by the wording of the original TrueType and OpenType / OFF specifications should be addressed at the source. Ideally, we should ask/propose that OT and OFF text should be clarified and made more specific. I doubt that we can solve this problem by attempting to use WOFF spec to explain how OT/OFF spec should be interpreted.

While I agree that it would be good to see the wording of the OT/OFF 
specs revised, I don't think this obviates the need to explain how the 
OT/OFF spec should be interpreted in the context of WOFF, especially not 
when the EOT web font spec necessarily has a conflicting interpretation. 
Also, initial pushback from MST on the idea of changing the fsType 
definition in the OT spec wasn't positive.

Received on Tuesday, 18 May 2010 18:38:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 20 January 2023 20:16:58 UTC