RE: Agenda, action items and suggested WOFF changes

On Monday, May 10, 2010 11:12 PM John Hudson wrote:
> 
> John Daggett wrote:
> 
> >> WOFF creations tools MUST verify that a font
> >> converted to the WOFF format does not have
> >> font embedding permissions set to ‘Restricted
> >> License Embedding’, and SHOULD generate an error
> >> message when this condition is encountered.
> >> Fonts that have “Restricted License Embedding”
> >> set as the only level of embedding allowed
> >> MUST NOT be converted to WOFF format.
> 
> > This is implicitly inferring that "restricted license embedding"
> > implies "no web use"; it may be the common case but it can't be
> > *assumed*. For example, a font designer could decide that WOFF use
> via
> > a particular service is fine but the font shouldn't be embedded when
> > a webpage is printed to PDF.  Document embedding and web linking are
> > very distinct uses, I don't think we should blur that distinction.
> 
> While I generally agree that embedding and linking are distinct --
> despite the vagueness of the OT/OFF spec and the confusion introduced
> by EOT's treatment of embedding bits -- I'll note that the OT/OFF spec 
> is uncommonly explicit with regard to 'Restricted License Embedding':
> 
>  Fonts that have *only* this bit set *must not be
>  modified, embedded or exchanged in any manner*
>  without first obtaining permission of the legal
>  owner.
> 
> I read this as referring not only to document embedding, however that
> is to be understood in terms of the OT/OFF spec, but to 'any manner' 
> of exchanging a font, including web linking. This is why I think this
> particular bit setting may legitimately be interpreted as prohibiting
> WOFF creation.

This was my understanding as well, and this is why the only condition I suggested to consider is the one when this bit is the *only* bit set in 'fsType' field. The spec for this particular setting is very explicit indeed, and prohibits the exchange of font data *in any manner*.

> 
> That said, the example you cite of webpage-to-PDF printing is an
> interesting one, and may be a compelling reason to exclude even
> 'Restricted License Embedding' from web font consideration.
> 
> There are some reserved bits in the fsType array, so perhaps the
> solution would be to have one of these assigned to 'No web font use
> allowed'? I suspect this could be spec'd and agreed within the
> timeframe
> of the WOFF standardisation, and would enable us to reference this new
> bit with regard to WOFF creation.
> 

If we decide to go this route, we need to initiate a proposal for amendment via the liaison between W3C and SC29/WG11. The next WG11 meeting will be held on July 26-30 and, according to the ISO rules and current WG11 schedule, this amendment would be completed in October 2011.

Regarding the proposed new bit setting and description: The default setting for all reserved bits is currently 'zero'. I am concerned that defining the new bit as proposed ("No web use allowed") would automatically make all existing fonts 'allowed' for web use, which I doubt has ever been an intent. The reversed interpretation "Web use allowed" would be safe with regard to existing fonts, and it would also play nicely with the existing definition of other embedding restrictions, including "Restricted License Embedding" - if both bits are set it would be clearly understood that document embedding is restricted while web use is allowed.

Regards,
Vlad

Received on Tuesday, 11 May 2010 14:37:16 UTC