Re: Next step?

On Thu, Oct 22, 2009 at 9:49 AM, Sylvain Galineau
<> wrote:
>> From: Levantovsky, Vladimir
>> I believe that the goal of the working group *is* to specify the
>> format(s) that hasn't been shipped yet to promote its implementation
>> and interoperability between browsers. Just because something didn’t
>> happen yet doesn't mean that it shouldn’t happen in the future - this
>> is exactly where the WG efforts would create most value.
>> To the contrary, whatever has already happened is the reality we live
>> with, and while the WG has to consider it in order to enable web
>> authors do what they need to do sooner rather than later, I don’t see
>> the need to simply rubberstamp any of the existing solutions unless it
>> promotes interoperability.
> Rubberstamping is precisely what I have no interest in. Interoperability
> in a relatively distant future should not take precedence over
> interoperability between now and then if it is possible, even if limited
> by legacy implementation issues. Not without detailed considerations of
> said limitations and consulting with authors, at least.

That said, let's talk details.  All the formats are pretty stable.
WOFF and CWT still need full specs, but we at least know what we're
getting into with them, so we can discuss them alongside the maturer

So, we've got four formats on the table.  SVG, TTF, CWT, and WOFF.

SVG Fonts is sort of a non-starter.  I don't think it's controversial
to say that it's not really equivalent to the other font formats as a
full font solution.  It's useful for integration with SVG and for
achieving cool SVG-driven effects involving fonts on web pages, but
the font files are *much* larger and I don't believe any of the
browsers that support them do so fully, or really plan to do so in the
near future (especially in regards to the complex character
relationships required for a lot of non-Latin languages).  Also, I
have no idea what the level of tool support is for creating SVG Fonts
from TTF fonts.

TTF is great.  It's simple, it's easy, and everybody already has
rendering support for it (you have to, since that's what the system
libraries use).  But it's contentious.  Many font vendors don't like
it, and the compat view is poor.  None of the old IEs support it, and
there's no indication that MS wants to support it at all.  If we're
looking for an ideal solution, here it is, but if we want a realistic
one, TTF is out.  The compat future is just too horrible, and that's
really the *entire point* of having a Font WG.

CWT and WOFF are the new guys.  They share many similarities, so I'll
hit those before discussing the differences.  Both of the formats are
modifications to plain TTF files, so conversion tools should be fairly
simple.  Both also effectively obfuscate the font, preventing it from
being dropped straight into a user's font folder.  However, neither of
them go any further than this - there is *no* DRM or DRM-like
substance to be found near them.  This doesn't make the font vendors
overly happy, but the obfuscation is enough for at least several
foundries to express support for them.  As DRM is a non-starter
anyway, this is probably the best we can achieve in terms of foundry

CWT has several advantages.  It's *extremely* simple - the TTF data is
present in the file in a completely unaltered form, ready to be passed
straight to a system library.  The only change is a header of a couple
bytes prepended to the font, which is composed of some magic numbers
and padding.  Using it is nothing more than checking the magic
numbers, looking at the offset, and then chopping the header off.  As
well, CWT has the significant compat advantage of working with legacy
IEs.  As was expressed many times before, legacy IE is the albatross
around the web's neck - users of other browsers update *much* faster
so we don't have to worry nearly as much about support timelines for
them.  By having this IE compat, CWT is the format with the shortest
expected time-to-usefulness for authors.  CWT doesn't really have a
downside - it's just TTF with a trivial processing step required.

WOFF also has significant advantages.  Again, it's also based on
ordinary TTFs, but it employs zlib compression on a per-table basis.
Tests show that this achieves *significant* size reductions,
substantially above what can be achieved with generic whole-file gzip
compression.  Due to the typical large size of font files, this is a
significant benefit for both authors and users - faster downloads, and
shorter FOUT.  However, its compat story isn't great; as a completely
new format, nobody supports it yet.  Firefox *just* announced support
for it in nightlies, but nobody else has made a public move yet.  It's
also somewhat more complex to decode, as you have to decompress the
font in a novel way.  ROC from Moz says that it's pretty easy and
shouldn't stop anyone, but it's still obviously more work than just
chopping off a header.

Summary time!  SVG Fonts should be supported on their own merits, but
really aren't a believable general solution to fonts on the web.  TTF
would be nice, but the expected time-to-usefulness is the highest of
all of them, because we have no idea when or if MS will ever support
them in IE.  CWT has great compat and will be usable the fastest, all
things being equal, but WOFF has the advantage of some very attractive
compression .

So I'm not sure why we're debating this.  TTF isn't an option right
now for a single-font-usable-everywhere, unless MS throws us a
curveball.  CWT is the best solution in the near term, and WOFF is the
best solution in the medium term.  So we should mandate support for
CWT and WOFF.  Anything else is just playing politics when we should
be making the lives of authors (like me) easier.


Received on Thursday, 22 October 2009 15:46:00 UTC