W3C home > Mailing lists > Public > www-style@w3.org > June 2009

RE: New work on fonts at W3C

From: Levantovsky, Vladimir <Vladimir.Levantovsky@MonotypeImaging.com>
Date: Thu, 25 Jun 2009 12:37:45 -0400
Message-ID: <E955AA200CF46842B46F49B0BBB83FF2924E7A@wil-email-01.agfamonotype.org>
To: "Aryeh Gregor" <Simetrical+w3c@gmail.com>, <robert@ocallahan.org>
Cc: "Brad Kemper" <brad.kemper@gmail.com>, "Jonathan Kew" <jonathan@jfkew.plus.com>, <www-style@w3.org>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:19 GMT