RE: text to path conversion API proposal

This discussion harkens back, perhaps,  to the still slightly disputed question of whether or not performance on a test suite can ever be performed automatically, or whether human judges will always be needed to judge browser compliance with the spec.

One important use case, simply because of the deep pockets of the interested parties, though, is corporate logos.  Companies want control not just over the precise shape of their logos (fearing trademark dilution when things diverge too far from the registered marks), but over the metadata embedded therein as well. It's easiest to do the former with bitmaps and the latter with vectors. Ultimately, however, the text that is embedded in logos (as with most of the world's trademarks) should really be text for purposes of searchability, accessibility, and comprehensibility. A sort of dialectic exists between semantic and geometric precision.

Cheers
David

-----Original Message-----
From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf Of Cameron McCormack
Sent: Sunday, October 23, 2011 11:49 AM
To: Dirk Schulze
Cc: Rik Cabanier; www-svg@w3.org
Subject: Re: text to path conversion API proposal

On 23/10/11 2:22 AM, Dirk Schulze wrote:
> And I'm pretty sure that we will never get same path results across
> platforms. But I assume that platform independent results are needed by
> web developers who want to use this feature. Or is that not so
> important? On WebKit I can just guarantee that for SVG Fonts, because
> the path data of every glyph is already known and independent of the
> various WebKit ports.

The question of consistency across different implementations/platforms 
is worth asking.  And even though you might be able to get the exact 
same individual glyph paths out, the result of performing the text 
layout might depend on system libraries, which means the positions of 
the glyphs might be different.

> Should the path data of every single glyph include all transformations
> (scaling, rotating, stretching)? I think that this makes most sense. In
> which userspace are the information provided? In the userspace of the
> <text> element?

I don't think it makes sense to apply the transformations due to 
transform="" to the path data returned.  The path data should just be in 
the coordinate system of the <text> element.  Scaling or rotations due 
to lengthAdjust="" or rotate="" should be applied though.

>    // Return an SVGPathSegList representing the entire geometry of the text content element,
>    // including glyphs and decorations.
>
> Why should the path data include text decorations like underline,
> line-through and overline? Can't web developers add these data them
> self? I would expect that the normal glyph data (with font styles) are
> more important.

Positioning and sizing decorations can be non-trivial to get right, and 
in particular to match what the implementation is rendering, if you 
don't know what font is being used.  I agree about normal glyph data 
being more important, though.

I added these concerns to the list of issues on the wiki page.

Received on Sunday, 23 October 2011 16:51:16 UTC