W3C home > Mailing lists > Public > www-svg@w3.org > January 2013

Re: SVG 2 Features and Approach

From: Doug Schepers <schepers@w3.org>
Date: Fri, 11 Jan 2013 14:15:32 -0500
Message-ID: <50F064D4.80905@w3.org>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: Charles Lamont <charles@gateho.gotadsl.co.uk>, www-svg <www-svg@w3.org>
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:
>> But mere font outlines is to completely miss the the reason for wanting SVG
>> fonts. It is all the other possibilities that make them attractive to the
>> end user.
>
> It's not *quite* mere font outlines - iirc, you can do multi-colored
> text in the FF implementation, for example, which means it's
> sufficient to support simple colored emoji.
>
>> I have had a few private emails suggesting there is a fair amount of end
>> user desire for this functionality, and dismay that is being kicked into the
>> long grass again, or even into oblivion. Why is it so painful to implement
>> anyway (as non-technical as possible, please)?
>
> I'm not the best person to ask,

Apparently not... :D


> 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
* the inability to use underlying font engines to manage layout and 
rendering
* the resulting performance problems from both of these
* the difficulty of maintaining a separate font code branch
* the lack of kerning or hinting in SVG Fonts
* various internationalization problems (including the one above)
* probably others

Since I'm not an implementer, I can't say how hard or easy any of these 
factors is to overcome. I will say, however, that most browser vendors 
(with Opera as a notable exception) have been quite intractable on the 
issue, and in absence of the expectation of interoperable 
implementations in all the browsers, I personally do not feel like SVG 
Fonts should be included in SVG 2.

This makes me sad, because I really like SVG Fonts, but I strongly feel 
that SVG 2 should be as reliable and interoperable as possible, for the 
sake of both authors and users (and I believe that this is the 
predominant sentiment in the SVG WG).


> If SVG fonts was nothing more than path data and the font metrics,
> plus perhaps some stroke/fill support, it's very likely it would be
> much less controversial.  But the SVG WG hasn't attempted to cut down
> the spec to that level, and so in the absence of that, browsers have
> generally just rejected it, or implemented only a small subset of it
> (and not spent much effort on bugfixing that subset).

This just isn't correct, sorry.

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.

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). I've run into 
other problems in the past that I don't recall now, but if we were to 
push for SVG Fonts to be its own module, we should get some font experts 
involved and really make the best of a new option... assuming we can get 
implementers on board.


[1] http://www.w3.org/TR/SVGTiny12/fonts.html

Regards-
-Doug
Received on Friday, 11 January 2013 19:15:41 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:53 GMT