Re: New work on fonts at W3C

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?

> 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.  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 Wednesday, 24 June 2009 23:07:34 UTC