RE: Agenda, action items and suggested WOFF changes

My original proposal [1] was based on two underlying assumptions:
1) User agents (namely browsers) should use downloaded resources to render and display the content as specified by the author (who is expected to obtain proper licenses) - therefore there would be no need for a browser to check the level of font embedding permissions.
2) Restricted License embedding has a very broad definition saying that fonts "must not be modified, embedded or exchanged in any manner without first obtaining permission of the legal owner" [2] - therefore this level would be incompatible with the web font use and this condition, if encountered, should be flagged.

The discussion that followed outlined different points of view and various use case scenarios. In particular, John Daggett presented a plausible scenario where *restricted license embedding* could be set in fonts licensed for web use [3], and Håkon has presented the case where user agents may need to pay attention and honor embedding restrictions [4].

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
- to imply that current embedding permissions settings are relevant to web use by requiring tools to check them.

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.

Regards,
Vladimir


[1] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010May/0045.html
[2] http://www.microsoft.com/typography/otspec/os2.htm#fst
[3] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010May/0047.html
[4] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010May/0072.html
[5] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010May/0094.html
[6] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010May/0071.html
[7] http://lists.w3.org/Archives/Public/www-font/2010AprJun/0133.html


> -----Original Message-----
> From: John Hudson [mailto:tiro@tiro.com]
> Sent: Monday, May 17, 2010 3:55 PM
> To: rfink@readableweb.com
> Cc: 'Thomas Phinney'; Levantovsky, Vladimir; 'John Daggett'; 'Chris
> Lilley'; public-webfonts-wg@w3.org; www-font@w3.org
> Subject: 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 23:18:45 UTC