- From: Erik Dahlstrom <ed@opera.com>
- Date: Mon, 14 Jan 2013 17:17:04 +0100
- To: "Tab Atkins Jr." <jackalmage@gmail.com>, "Doug Schepers" <schepers@w3.org>
- Cc: "Charles Lamont" <charles@gateho.gotadsl.co.uk>, www-svg <www-svg@w3.org>
Hi Döug, everyone, On Fri, 11 Jan 2013 20:15:32 +0100, Doug Schepers <schepers@w3.org> wrote: > Hi, folks- > > On 1/11/13 1:10 PM, Tab Atkins Jr. wrote: >> On Fri, Jan 11, 2013 at 3:06 AM, Charles Lamont wrote: ... >> as I have only tangential knowledge of >> the troubles with fonts, but from what I understand the problem is >> simply the shear quantity of things you can do with full SVG. For >> example, you can embed videos, external documents, foreignContent, >> animations, filters, and a bunch more. This stuff is just *crazy* >> compared to what any other font format allows, and it's a lot of >> effort (and a lot of potential security issues) to implement compared >> to normal fonts. > > That's correct, but it's only part of the story. > > Other difficulties include: > * the large DOM that results from so many glyph elements IMHO very large/unicode-complete fonts is not really the primary use-case for SVG Fonts. Though it's possible to avoid bloating the main document's DOM by using external SVG Fonts. > * the inability to use underlying font engines to manage layout and > rendering As an implementor I disagree. It is possible to reuse a portion of the structures used for fonts in general, it mostly comes down to good architecture. I also think that avoiding the "regular font engine" in itself is a feature - to step outside what can be done with "regular" fonts. > * the resulting performance problems from both of these I see this a tradeoff between the use-cases, SVG Fonts were not meant to be used for large blocks of text, but for decorations, logos, animated smileys or what-have-you... It's plenty fast for the use-case it's indented for. And it comes with the side-effect of keeping text accessible and looking identical in all viewers that support SVG Fonts. > * the difficulty of maintaining a separate font code branch Maybe, but then again, how often do the font code branch for OpenType fonts change in browsers? Also, I see the separation as a feature. > * the lack of kerning or hinting in SVG Fonts Kerning is supported in SVG Fonts (<vkern>, <hkern>). Hinting is perhaps getting less important these days due to HiDPI screens. And what about hinting for svg in general? > * various internationalization problems (including the one above) It's more a lack of data tables, for complex shaping and so on. It's entirely possible to represent these in XML, but no one seems interested enough to do this. OTOH the svg-in-opentype idea suffers from much the same problems that SVG Full Fonts have, in the sense that they too need restrictions and custom rules (a spec in other words). You'd get more for free by representing the necessary OpenType tables in SVG Fonts rather than the other way around. And you lose a lot of flexibility by going down the svg-in-opentype route IMHO. ... > SVG Tiny 1.2 defines just this effective subset of SVG Fonts [1]; this > is what's supported in Opera and WebKit, and this is what Erik Dählstrom > (Opera) is lobbying to include in SVG 2. Only the refusal by the > Internet Explorer and Firefox teams to support this makes it difficult > to include in SVG 2. Pragmatically, I'm sympathetic to their positions, > but I'm ambivalent on the outcome. I'm weighing this against the support for svg-in-opentype, which is experimental at this stage, versus something that does work in multiple implementations and which has a stable spec (SVG Tiny 1.2 fonts). Practically, the use-case I've seen of svg-in-opentype this far: animated multi-colored emoji. Nothing making use of the i18n features, complex scripts and such. > That's not to say that SVG Fonts wouldn't benefit from several > improvements. Adding kerning, hinting (possibly through Media Queries?), > and solving other internationalization issues would be a start. Making > them behave more like other SVG rendering elements would also be a boon; > the mirrored top-down coordinate system and huge default sizing for > glyphs may have matched other font formats, but it's extremely > unintuitive and inconvenient for SVG authors (and authoring tools could > easily have made the conversion to other font formats). These are issues that could be addressed, but they should be weighed against the relevant use-cases. Cheers -- Erik Dahlstrom, Core Technology Developer, Opera Software Co-Chair, W3C SVG Working Group Personal blog: http://my.opera.com/macdev_ed
Received on Monday, 14 January 2013 16:17:44 UTC