- From: Adam Twardoch (List) <list.adam@twardoch.com>
- Date: Wed, 29 Jun 2011 17:20:38 +0200
- To: "www-font@w3.org" <www-font@w3.org>
- CC: www-svg@w3.org, "www-style@w3.org" <www-style@w3.org>, "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>, OpenType List <opentype-migration-list@indx.co.uk>
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:09 UTC