Re: Agenda, action items and suggested WOFF changes

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.

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

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

JH

Received on Tuesday, 18 May 2010 03:24:56 UTC