Re: EOT and EOT-based proposals

Patrick Garies wrote:
> Tab Atkins Jr. wrote:
>>  So, let's talk details.
> 
> It seems that the positions are:
> Microsoft: No OTF/TTF; Yes EOT or "EOT Lite"
> Mozilla: Yes OTF/TTF; No EOT or "EOT Lite"
> Apple/WebKit: Yes OTF/TTF(; No EOT or "EOT Lite"?)
> Opera: Yes OTF/TTF(; No EOT or "EOT Lite"?)

I agree partially. As I see it, the status is

Microsoft: No OTF/TTF, Yes EOT (and possibly EOT Lite)
Mozilla: Yes OTF/TTF, No EOT, Unknown EOT Lite
Apple/Webkit: Yes OTF/TTF, No EOT, Unknown EOT Lite
Opera: Yes OTF/TTF, No EOT, Unknown EOT Lite

Here the EOT Lite is EOT without rootstrings at all and without
compression (which is the patented part of EOT). User agents may
implement same-origin restrictions and CORS with EOT Lite.

If I've not misunderstood, it's possible to implement EOT Lite without a
patent license at all. Especially, a GPL licensed implementation is
possible.

Where do you see evidence that Mozilla/Apple/Opera would not implement
EOT Lite?

> Tab Atkins Jr. wrote:
>>  First, are there any legal issues preventing any of the other
>>  browsers (particularly Firefox with its GPL obligations) from
>>  implementing EOT? I don't believe there is any, but I want to make
>>  absolutely sure.
> 
> I believe someone mentioned wanting to see the patent license while the
> patent holder refuses to incur expenses for writing such a license until
> someone commits to implementing EOT. So, presumably, that depends on
> what the as-of-yet unwritten license says.

As far as I know, the said yet-to-be-done patent license is about MTX
compression part of EOT. The interoperability can be implemented with a
restricted EOT format EOT Lite which does not include compression at all
and as such, cannot infringe compression patent.

> Tab Atkins Jr. wrote:
>>  Third, can we add same-origin restrictions to EOT?  These obviously
>>  wouldn't do anything with legacy IE versions, but it *would* be
>>  interoperable with all new versions of all browsers.
> 
> Doesn't this create another one of those situations where the browser
> that ignores the standard renders things "better" resulting in the
> non-compliant browser gaining more market share (and hence why certain
> vendors have refused to implement certain standards)? This is more
> interesting considering Microsoft's Compatibility View, which,
> presumably, would render the page without these restrictions (and, thus,
> "better") even if Microsoft committed to implementing it in a later
> version.

If Microsoft did implement same-origin restrictions similarly to other
browsers and pushes such version in a same way as MSIE8 (as a security
fix that should be installed by everyone), I have no problem. Any user
that installs all security fixes would get the same result with IE as
with any other browser.

Also, if same-origin restriction and CORS are implemented in a way that
allows user and/or user agent override the restrictions, then a
compliant user agent may allow rendering the content the same way as any
compatibility mode in any other browser (except for the compressed EOT
fonts, due to software patents, of course).

-- 
Mikko