Re: fsType and embedding information (was: Agenda, action items ...)

I agree with the emerging consensus here. Short version: Leave fsType out of it.

John, I understand what you're saying, but I am still unconvinced that any explanation is necessary. I don't see much harm in providing any such explanation, so I'm not going to argue strongly against it... but I don't plan to argue strongly for it, either.

-Christopher

On May 18, 2010, at 11:38 AM, John Hudson wrote:

> 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.
> 
> JH
>

Received on Tuesday, 18 May 2010 23:32:15 UTC