Re: Next step?

On Thursday, October 22, 2009, 5:45:06 PM, Tab wrote:

TAJ> SVG Fonts is sort of a non-starter.  I don't think it's controversial
TAJ> to say that it's not really equivalent to the other font formats as a
TAJ> full font solution. 

I agree that its different to the other ones on the table, in that the other three are all different formulations of OpenType. Its also different in that no one (to my knowledge) is proposing it as *the* font format for the Web.

TAJ>  It's useful for integration with SVG and for
TAJ> achieving cool SVG-driven effects involving fonts on web pages,

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.

TAJ> Also, I have no idea what the level of tool support is for creating 
TAJ> SVG Fonts

Adobe Illustrator, Corel Draw, Inkscape and Fontforge all create them.
 
TAJ> from TTF fonts.

The Apache Batik project has a converter for TTF to SVG.

TAJ> TTF is great.  It's simple, it's easy, and everybody already has
TAJ> rendering support for it (you have to, since that's what the system
TAJ> libraries use).

(On the desktop and on high-end to midrange mobile, yes.)

TAJ>   But it's contentious.  Many font vendors don't like
TAJ> it, and the compat view is poor.  None of the old IEs support it, and
TAJ> there's no indication that MS wants to support it at all.  If we're
TAJ> looking for an ideal solution, here it is, but if we want a realistic
TAJ> one, TTF is out.  The compat future is just too horrible, and that's
TAJ> really the *entire point* of having a Font WG.

Good summary. 

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.

TAJ> CWT and WOFF are the new guys.  They share many similarities, so I'll
TAJ> hit those before discussing the differences.  Both of the formats are
TAJ> modifications to plain TTF files, so conversion tools should be fairly
TAJ> simple. 

And already exist, for both.

TAJ>  Both also effectively obfuscate the font, preventing it from
TAJ> being dropped straight into a user's font folder.

Its a pretty low garden fence, but yes.

TAJ>   However, neither of
TAJ> them go any further than this - there is *no* DRM or DRM-like
TAJ> substance to be found near them.  This doesn't make the font vendors
TAJ> overly happy, but the obfuscation is enough for at least several
TAJ> foundries to express support for them.  As DRM is a non-starter
TAJ> anyway, this is probably the best we can achieve in terms of foundry
TAJ> happiness.

I agree that it seems to be enough to make 

TAJ> CWT has several advantages.  It's *extremely* simple - the TTF data is
TAJ> present in the file in a completely unaltered form, ready to be passed
TAJ> straight to a system library.  The only change is a header of a couple
TAJ> bytes prepended to the font, which is composed of some magic numbers
TAJ> and padding.  Using it is nothing more than checking the magic
TAJ> numbers, looking at the offset, and then chopping the header off. 

Right.

TAJ>  As
TAJ> well, CWT has the significant compat advantage of working with legacy
TAJ> IEs. 

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.

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.

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.

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.

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.

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

TAJ> So I'm not sure why we're debating this.  TTF isn't an option right
TAJ> now for a single-font-usable-everywhere, unless MS throws us a
TAJ> curveball.  CWT is the best solution in the near term, and WOFF is the
TAJ> best solution in the medium term.  

With you so far.
 
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.


-- 
 Chris Lilley                    mailto:chris@w3.org
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Thursday, 22 October 2009 17:35:41 UTC