Re: Agenda, action items and suggested WOFF changes

Rich, I think you are reading too much into Tom Phinney's attempts to 
future-proof possible language related to fsType embedding bits. The 
fact is that there is a small number of reserved bits in that field, and 
we -- none of us -- have any ideas what they might be used for in 
future. Personally, I think it is very unlikely that they will be used 
for anything related to WOFF or to webfonts in general, since the fsType 
field is specifically related to 'document embedding', and the primary 
purpose of putting something in the WOFF spec about fsType is to clarify 
that this field is *not* webfont related. Unfortunately, we can't do 
this in a general way, because the EOT spec says the embedding bits are 
webfont related, so we have to approach this in a format-specific way, 
in the WOFF spec.

Let's back up a minute, and look at where we are and why, because if we 
start speculating about possible futures or possible motivations, we'll 
lose sight of a actual motivations for raising this subject.

Some of use font makers want to formally clarify that existing fsType 
embedding bits do not relate to serving WOFF files on the web. I see 
this as a positive thing for everyone involved: it makes clear that 
browsers are doing the right thing by ignoring these bits, it makes 
clear that these bits do not provide legal permission to make and serve 
WOFF files, and it removes ambiguity for web authors. That is all I had 
in mind when I dragged these bits to the table for discussion.

Vlad proposed some language that introduced the possibility that 
embedding bit 1 might prohibit creation of a WOFF file. This wasn't on 
my original agenda, but it seemed worth some discussion. The definition 
of embedding bit 1 is very broad, and it can easily be interpreted to 
apply to something like WOFF creation. That alone is good reason to 
explicitly state in the WOFF spec whether this is or is not the case.

John Daggett pointed out that there were practical problems with 
embedding bit 1 with regard to WOFF, since a font might be licensed for 
WOFF but prohibited from embedding in a document. This is the juncture 
at which I suggested that these practical problems could be addressed by 
defining a new fsType bit, specific to WOFF.

BUT THIS WAS ONLY A SUGGESTION FOR A TECHNICAL SOLUTION TO A TECHNICAL 
PROBLEM... it was not my intention to say that such a thing should be 
done, that such a thing was in the interest of WOFF, only that it could 
be done and would resolve the problem identified by John D. Whether it 
appeals at all depends on whether font makers have an interest in a 
technical means to prevent creation of a WOFF file from a given font. So 
far, response from the few colleagues whom I have asked has been 
negative or ambivalent.

Personally, I'm back to my original position which was that the WOFF 
spec should simply clarify that a) embedding bits must be ignored by 
user agents receiving and displaying WOFF files, and b) embedding bits 
do not constitute permission to create or serve WOFF files. That's it.

I think Tom's concerns about future proofing the language are 
legitimate. If possible we should avoid creating a situation in which 
what need to be interoperable standards might produce conflicting 
requirements. There seem to me two ways to do this: either make the WOFF 
spec language specific to currently defined embedding bits only, as Tom 
suggests, or decide here and now that fsType bits only ever refer to 
document embedding and should never relate to WOFF creation, serving or 
displaying. Personally, I'm happy with the latter approach.

JH

Received on Monday, 17 May 2010 19:56:11 UTC