Re: SVG Fonts inside of OpenType fonts? [Cross-post from www-font@w3.org]

I must admit that Vlad's post about the necessity for having a glyph
index-based selection of glyphs in an SFNT+SVG solution because we don't
want to force the font developer to provide SVG versions of all the
glyphs (if we want to proceed with the "fallback" mechanism meaning that
a "glyf" or "CFF " table would be provided along) made me think that my
original proposal has some drawbacks.

Obviously, my main principle behind proposing the solution was to come
up with a format that is the simplest possible to implement. But now I
realize that it's not just soooo simple to stick the entire SVG font
into SFNT and not worry about anything else.

So, let me reshape my main points as follows:

1. The most important motivation behind my proposal is to have the
ability to have fonts which can use arbitrary colors, multiple outline
layers, and include bitmaps. Perhaps also animation, if a client
supports it (with the possible fallback of "first frame as static image"
in non-animated context). I don't really care so much for the precise
technical implementation, and my own implementation proposal was just
input for discussion. I'm very glad that the discussion has emerged, and
people have provided valuable feedback so far.

2. I do realize now that using ALL of the SVG Font inside of SFNT does
create important problems: first, the glyph selection is not easily
solved (except if we either provide an additional table or add
attributes to the SVG glyphs). Second, there is significant overhead in
the SVG Font spec which would need to be ignored by the client that
implements SFNT+SVG.

3. One key thing that I've realized long ago is that in a way, these
days the layout systems are more complex and more difficult to "get
right" or implement that the glyph rendering. This is why I proposed
this SFNT+SVG at all. I have a strong conviction that coming up with a
completely new, XML-based format that would encompass all of a layout
system's needs (alternative glyph selection, complex script support,
mark attachment etc. etc.) would be a huge undertaking. Neither of the
existing SFNT-based layout systems (OpenType Layout, AAT, Graphite etc.)
are perfect, but they're all workable and well-tested. And we have tools
to develop such fonts. So I believe it is only right to rely on them,
i.e. build on the foundation of SFNT. It's the best that we have, we
have it now, and an alternative is very unlikely to emerge anytime soon.

4. The above does not mean that all efforts should stop to come up with
some mythical "Fonts 2.0" system that will supersede all that we've had
so far. But before (if ever) we come up with this "egg-laying
wool-milk-sow" (Eierlegende Wollmilchsau, a funny German phrase that
could be approximated by "the Swiss army knife") of fonts, we need
workable solutions. Those approaches are not mutually exclusive.

All in all, I'm now more in favor of Adobe's proposal, which basically
dissects the SVG Fonts into glyph definitions, and packs them into a
more native SFNT form. Since we don't really need ALL of the SVG Font
inside of SFNT, a format such as the one proposed by Adobe is probably a
much better solution. And independent of this, people are of course free
to follow the alternative path of expanding the SVG Font spec into a
fully XML-based font format that is as strong in future with respect to
text layout as it is now with glyph rendering. But as I said many times
-- developing this is a song of future.

In short: since Sairus Patel has already done the work of proposing a
table format for SVG glyph definitions inside of SFNT, I support it.

Best,
Adam

Received on Wednesday, 29 June 2011 15:21:19 UTC