Re: Agenda, action items and suggested WOFF changes

Thomas Phinney wrote:

> Hurm. I have a practical concern with that. What would we expect UAs
> to do with fonts they encounter that don't have that bit set? Reject
> them all? That hardly seems practical, and I would expect the browser
> folks to object strenuously to this if that was the expectation. If
> that was *not* the expectation, I don't see much use for the bit.

There is no expectation at all on UA agents. The proposed text re. 
embedding bits is that UA's will ignore them completely. The question 
regards tools for creating WOFF files.

> In fact, the only obvious ways I see out of that are to either:
> 
> 1) Bump the OS/2 table version so that UAs can know the bit means something

Yes, I assume that would be done in any case if a new bit were assigned. 
We can link the version and bit interpretation in conformance.

> 2) have TWO mutually exclusive bits for this new function. One
> explicitly says web use allowed, the other explicitly says it's
> disallowed.

Is that really necessary if the table version acts as a filter for 
interpretation of a single bit?

> I also have an independent concern: what *kind* of web use is implied
> by the bit. It seems like foundries are all over the place today in
> what kind(s) of web use they are okay with (if/when they allow any).
> Does this bit mean WOFF is okay? What about EOT? Cufon? Flash? SVG?
> Naked fonts?

I'd be happy for it to be explicitly WOFF related: 'WOFF file creation 
permitted'. EOT already has its own interpretation of embedding bits. We 
can't anticipate all the possible ways in which typography might be 
served on the web, and at the end of the day the EULA has to handle 
things like Cufon, Flash, etc. But since WOFF is being defined as a 
standard we can be more specific.

JH

Received on Tuesday, 11 May 2010 18:18:22 UTC