Re: Next step?

On Oct 22, 2009, at 1:51 PM, Sylvain Galineau wrote:

> EOT is documented in a W3C submission. John's post describes the CWT  
> subset
> adequately for an implementor.


Right. Are any of the follow up messages relevant?

Will you be disclosing IE's (and t2embed's) expectations about the  
font data? Something that is called "Compatibility" should have a  
clear set of specifications about what is required to make it  
compatible with the thing that "Compatibility" refers to. In addition  
to the defined EOT specification, these are the expectations that I  
know of:

1. The font must be TrueType flavored, not CFF.
2. No name table entry must be larger than 5000 bytes.
3. The full name (id 4) entry in the name table must start with the  
string defined in the family name (id 1) entry.
4. Style linking must be defined in the font since the CSS style  
linking is overridden by the font data.
5. The OS/2 fsType must not be set to "no-embedding."

Are there more? If the point is compatibility with IE, then the  
requirements for compatibility with IE need to be defined. Font  
vendors must know this so that we can make our fonts meet these  
expectations, web developers will need to know these things so that  
they can be assured of compatibility and, I think, all browsers should  
have to implement the same set of expectations so that  
interoperability is truly achieved.

To be clear, I am not endorsing CWT and I am not speaking as a co- 
author of the WOFF specification. I am speaking as someone who works  
with a number of foundries to produce fonts and as someone who  
actually experimented with EOTL. Font makers already have enough  
undefined expectations and bugs to guess about and work around. I  
quite strongly do not want to have more of these. It's bad for  
everyone involved -- the OS/app makers, the font makers and, most  
importantly, the users.

Tal

Received on Thursday, 22 October 2009 18:35:50 UTC