Re: text to path conversion API proposal

On 10/21/2011 12:18 PM, Cameron McCormack wrote:
> Thanks for the questions, Dirk.
>
> On 21/10/11 2:59 PM, Dirk Schulze wrote:
>
>> What do you expect for benefits, when do we need that?
>
> So that authors can use script to perform their own processing and
> effects on text.  In writing a demo to do some warping of text along a
> path, I needed the path data for the text.  I instead had to open
> Inkscape, convert my text to a path, and embed the path data in my
> document.  That's not going to work for text chosen at run time.

I second this case. We've worked with quite a few path filters and 
currently need to embed SVG fonts to do any of this work.
It would be nice to be able to use WOFF as it seems SVG Fonts are 
currently shunned by Mozilla development.

>> It must be transformed to SVG Path syntax somehow and I am not sure
>> how we get similar results across implementations for
>> SVGPathSegList.
>
> You are right that there is a risk there of sites ending up depending 
> on particular path data coming out of the API for a given font.

Font detection is a lot of work, regardless.
I've worked with font/glyph detection in CSS and Canvas.
The proposed SVG methods would be quite welcome in this area.

Cameron, would a measure text method be an appropriate addition to this 
proposal?
It would return width and dominant baseline offset for the text.

In Canvas we have had to use CSS to compute the area: hidden divs and 
getComputedStyle
I typically reference an image from documentation. Baselines example: 
http://images.whatwg.org/baselines.png

Various baseline effects can be scripted if the baseline and text width 
are available to the programming environment.

-Charles

Received on Friday, 21 October 2011 19:51:28 UTC