RE: New work on fonts at W3C

On Wednesday, June 24, 2009 7:07 PM Aryeh Gregor wrote:
> 
> On Wed, Jun 24, 2009 at 6:27 PM, Robert
> O'Callahan<robert@ocallahan.org> wrote:
> > This means fragmenting the EOT format into EOT-without-rootstrings,
> > EOT-without-compression, EOT-full, etc. In particular, if some
> browsers only
> > support EOT-without-rootstrings but font vendors require their fonts
> to have
> > rootstrings, nothing much has been gained except confusion (and
> perhaps an
> > opportunity has been lost).
> 
> Why would font foundries be okay with Ascender's proposal, but not EOT
> minus RootString plus CORS?
> 

Fragmenting EOT to the point where interoperability is lost is not a good idea. 
However, I fully support Aryeh's position - dropping (or ignoring or leaving empty) RootString in favor of same-origin restriction and CORS is a perfectly viable solution.

> > Echoing what John D said earlier, I'm personally comfortable with
> Ascender's
> > proposal, and I'd support shipping it in a future version of Firefox
> > (alongside support for plain TT/OT).
> 
> What advantages does it have over EOT with some features dropped?  The
> page says:
> 
> * "As a Microsoft-centric technology first implemented in IE4 it gives
> Microsoft browsers an unfair advantage."  Competition should not
> prevent choosing the format that's best for users.  

+1! 
Billions of web users will benefit from simple code changes that only few browser vendors need to make.

> There are plenty
> of other bits of now-standard web tech reverse-engineered from IE, and
> everyone has benefited from the more rapid deployment of useful
> features.
> * "The compression uses patented Agfa (now Monotype Imaging)
> technology."  The patents are to be freely released, so this should be
> a non-issue.  If not, don't include it in the supported subset.
> * "The URL binding mechanism is similar to DRM schemes, opposed by
> free software activists. The URL binding mechanism (with or without
> subsetting) is too burdensome for larger site operators."  You could
> just not support RootString, and stick with CORS as now.  This would
> be functionally identical to Ascender's proposal AFAICT.
> 
> I don't think that browsers implementing different subsets would be at
> all confusing.  Web authors have long been used to facts like "you can
> use PNG but not with alpha channels, because IE6 doesn't support them"
> or "you can use CSS rule X but not Y, because browser Z doesn't
> support it".  It's not a big deal IMO as a web developer.  What you do
> is just forget about everything you can't use.
> 
> Once a universally supported subset of EOT is agreed upon, simple
> tools can be written that output that subset.  The procedure would be
> the same as any other proposal except raw TTF/OTF: stick in raw font
> file, get web font file.  If author confusion is a big deal, make up a
> new standard extension -- like .otw as Ascender has proposed.

Received on Thursday, 25 June 2009 16:38:18 UTC