Re: SVG 2 Features and Approach

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