Re: Next step?

On Thu, Oct 22, 2009 at 12:35 PM, Chris Lilley <> wrote:
> That's enough of a list to make 'non starter' seem odd :) but if you mean non-starter as the One True Format to rule them all then yes.

Yeah, that's what I mean.

> Although, some of the libre font guys seem to think that raw OT is the best solution for their fonts, and are asking why they should bother supporting WOFF as well.

Because of the compat story.  I don't think we've gotten anything like
an official word out of MS, but I *think* I can interpret Sylvain's
comments to mean that MS is cool with supporting WOFF.

> Sort of. The legacy IEs also have the disadvantage of CSS support that is way below what IE7/8 do. So the compatibility only gets you so far; dual design is still needed.

True, but it reduces the split code.  Demonstrations have been made
showing how to work around browser quirks to deliver what's necessary.
 I believe these are more complex than needed if you're feeding all of
the browsers the same file.

> TAJ>  As was expressed many times before, legacy IE is the albatross
> TAJ> around the web's neck - users of other browsers update *much* faster
> TAJ> so we don't have to worry nearly as much about support timelines for
> TAJ> them.  By having this IE compat, CWT is the format with the shortest
> TAJ> expected time-to-usefulness for authors.  CWT doesn't really have a
> TAJ> downside - it's just TTF with a trivial processing step required.
> It has the downside that some browser vendors don't like EOT and don't much like CWT either.

What's left to dislike about CWT, though?  EOT had several bits that
made it less than attractive - namel the DRM-like rootstrings and the
patented compression (at the time - let's not reopen the MTX
discussion ^_^).  But CWT has neither of those.  It's just TTF with a
header full of padding and a few magic numbers.

If there is *any* EOT hatred leaking over into CWT, it's misplaced.

> TAJ> WOFF also has significant advantages.  Again, it's also based on
> TAJ> ordinary TTFs, but it employs zlib compression on a per-table basis.
> TAJ> Tests show that this achieves *significant* size reductions,
> TAJ> substantially above what can be achieved with generic whole-file gzip
> TAJ> compression.
> There is also the possibility of downloading the header and table index, then using HTTP byterange requests to get the tables you most want, first.

Ah, awesome.  Didn't realize that was a possibility.  That just makes
WOFF even better.

> TAJ>  Due to the typical large size of font files, this is a
> TAJ> significant benefit for both authors and users - faster downloads, and
> TAJ> shorter FOUT.  However, its compat story isn't great; as a completely
> TAJ> new format, nobody supports it yet.
> Sure they do.
> TAJ>   Firefox *just* announced support for it in nightlies,
> Announcements and shipping code are different things. Firefox has code that people can use now. While announcements of future direction are all well and good (and its great to see this announcement), the fact that the announcement was preceeded by actual running code makes this more important and more credible.
> So your 'no-one supports it yet' is incorrect.

Sorry, didn't mean to imply quite what you responded to.  The latest
public release of FF doesn't support WOFF, correct?

> TAJ> but nobody else has made a public move yet.  It's
> TAJ> also somewhat more complex to decode, as you have to decompress the
> TAJ> font in a novel way.
> Its fractionaly more complex. Compared to the complexities of the rest of the layout process, its trivial. And the decompression uses an existing library that is already in all the browsers so they can deal with HTTP compression, and PNG decoding.
> TAJ>  ROC from Moz says that it's pretty easy and
> TAJ> shouldn't stop anyone, but it's still obviously more work than just
> TAJ> chopping off a header.
> Barely. I would say that any browser that already uses OpenType to render can (if they wish, and that's the crucial part) add support for CWT or WOFF or both with essentially no impact on total code size or ship dates.

Again, excellent.  I didn't mean to imply that it was difficult, but
Maciej expressed some concern about the complexity of WOFF in irc, so
I wanted to address it here.  I didn't think either format was very
difficult to implement, but wanted to ensure that it was understood
*exactly* what the decoding requirements were for CWT and WOFF.
(Again, Maciej thought at first that CWT still used XOR obfuscation.)

(Sorry to call you, Maciej!)

> TAJ> So we should mandate support for
> TAJ> CWT and WOFF.  Anything else is just playing politics when we should
> TAJ> be making the lives of authors (like me) easier.
> Mandating both is an interesting choice, but risks failure from any browsers that take a stand against CWT.

I don't see any reason to stand against CWT, honestly.  It has *none*
of the undesirable features of EOT.  It's nothing more than an
ordinary TTF file with a header prepended to it.  The only thing I
could possibly think of is just being against "TTF, but not" - that
is, being against a non-useful modification to TTF files solely to
break them on the desktop - but really?  Is the benefit to authors
worth so little that that trivial bit of modification kills the

I'd rather go ahead and take the stand so that people would have to
actively come out against it, rather than just ignoring it and letting
it die from neglect.  It's a short-term solution, but it's the *best*
solution in the short-term we have, so we either need to force it now
or ignore it entirely.


Received on Thursday, 22 October 2009 20:22:56 UTC