Re: text to path conversion API proposal

On 10/23/11 8:49 AM, Cameron McCormack wrote:
> 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.

What's the question being asked?

Michael Deal did some work in Canvas looking at fonts:
http://mudcu.be/journal/2010/11/unicode-profiling-project/

I've had to use invisible div hacks to get baseline information.

There will be inconsistent results. And, the glyph data itself when 
rendered may appear in a higher quality than the glyphs displayed by the 
OS font engine. It's often the case that text legibility/quality is 
lower in browsers than what is available as a means for faster rendering.


>
>> 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.

I agree.

>
>>    // 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 agree about decorations, they're hard to get right. Having additional 
information from the font, such as baseline offsets, is a big help in 
implementing underline, but it'd be nice to save that added work when 
possible.

-Charles

Received on Sunday, 23 October 2011 16:24:53 UTC