RE: EOT-Lite File Format v.1.1

On Fri, 2009-07-31 at 18:35 +0000, Sylvain Galineau wrote:

> >Therefore I (and I guess Tab) are asking for a positive
> >assertion both here and in any eventual Recommendation
> >that a UA is free to treat such "invalid" EOTL in the
> >manner I described - decompressing, ignoring root string,
> >rendering, and so forth - without risking violating a
> >patent or being accused of contributory infringement or
> >being a circumvention device.
> 
> If one could make such an assertion, why would we bother with
> EOTL in the first place ? 


Because EOTL is about what is to be *required* ("MUST")
to conform to a Recommendation while fully general
EOT support is what should be *recommended* ("SHOULD")
by a Recommendation.


> No one here can make that assertion
> except the patent holders and anyone who might claim such a
> circumvention occurred.

If consensus is formed around "SHOULD" for full
EOT support and "MUST" for EOTL support, and
if the MTX spec is referenced in a Recommendation
and patent assurances given, then the threat of such
claims is greatly diminished.

Conversely, while that assertion is absent,
the threat of such claims is substantial and 
is in and of itself a reason to object to EOTL.



> What I can assert is that no rootstring can be circumvented in
> the current EOTL proposal since they cannot even be stored in
> the file, and that any file using Monotype's patented technology
> must be rejected.

Which sounds like an unwillingness to endorse
the intention that conforming UAs are free to
implement the full EOT.

That is alarming.



> Ultimately, I do not see why an EOTL format spec would ever
> need or want to state that a UA is free to implement what parts
> of EOT it likes and ignore the parts it doesn't.
> 
> I'll let Tab explain what he means and answer him. This thread
> is closed.

You've told me everything *I* need to know about
MSFT's position on the matter.

-t

Received on Friday, 31 July 2009 18:53:10 UTC