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 15:49:55 UTC