RE: Agenda, action items and suggested WOFF changes

On Monday, May 17, 2010 11:24 PM John Hudson wrote:
> 
> Vlad wrote:
> 
> > In light of these arguments, it seems to be inappropriate for the
> WOFF specification:
> > - to provide a blanket statement saying that all user agents shall
> ignore embedding permissions - because it depends on specific use case
> and should be left up to the UA [4], and
> 
> The scenarios that John D and Håkon provided both involve generation of
> PDFs from web pages, i.e. document embedding from unpacked fonts. I
> believe it is both possible and appropriate to define user agent
> behaviour in which it makes sense to ignore embedding permissions.
> Downloading, unpacking and displaying a WOFF contained font within a
> user agent constitutes such behaviour. Subsequently embedding the font
> in a document does not.
> 

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

> > - to imply that current embedding permissions settings are relevant
> to web use by requiring tools to check them.
> 
> I agree this is inappropriate. Worse, I think this tool conformance
> issue has become a red herring that looks like derailing the simple and
> reasonable clarification that embedding bits are not relevant to the
> creation, serving, downloading or display of WOFF files.
> 
> > Since WOFF file format is supposed to be neutral to any specific
> flavor of SFNT-based font format, and because organizations and
> entities responsible for development and maintenance of existing font
> standards may in fact introduce future modifications that may be
> relevant to web font use (e.g. a new set of bits or a bitfield that may
> indicate specific conditions for web use), I tend to agree with Tom
> Phinney [5] (and others who expressed similar views) that it may be
> best for the WOFF spec to remain silent about embedding bits. I shared
> John Hudson's initial intent to clarify the relationships between the
> existing embedding permissions and WOFF, but I agree with John Daggett
> [6] and Sylvain [7] that an attempt to define conformant tool behavior
> isn't worth the distraction it creates.
> 
> But the tool conformance issue wasn't part of my original request for
> clarification of the embedding bits. From my perspective, as a font
> maker, there is only one thing that really needs to be said re. the
> existing embedding bits, and that is that they do not constitute
> permission to create or serve a WOFF file. 

Tool conformance issue was the result of overly broad definition of the existing "Restricted License embedding" and my interpretation of it as something that may be relevant to web use. I do not object to mentioning that the existing embedding permissions do not constitute permission to create or serve a WOFF file; however, I share the same concerns expressed by Tom P. that it is feasible font makers may decide they want to define some of the remaining reserved bits for web use purposes in the future, so we need to be very specific here.

> I figured browser and tool
> makers might also like to have it in writing that when they ignore
> these bits they are right to do so.

And so did I. 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.

> 
> Does maintaining the ambiguities created by the wording of the OT/OFF
> and EOT specs help anyone?
> 

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.

Regards,
Vlad

Received on Tuesday, 18 May 2010 08:21:54 UTC