text-to-path method RE: Allow getTotalLength() and getPointAtLength() for <circle>, <rect> etc

 

On Tuesday, April 28, 2015 8:06 AM

Amelia Bellamy-Royds 



wrote

 

+1  to that idea.  I had been thinking about this myself just last week.  

 

[…]

 

On that note, I don't think the text-to-path method has been specifically defined yet.  It could also be defined as a generic method on the SVGGeometryElement interface, so that shapes could also be converted to paths easily.  If it was called getNormalizedPath(), the method could also replace the live-updating normalized path properties on path elements, which browsers never implemented because of performance issues.  It could maybe be  getNormalizedPath(boolean animated) to flag whether you wanted to convert the current animated state of the path, text, or shape versus the base state. 

 

I’ve been playing a lot with word-art again recently (resurrecting examples that used to work only in ASV and Opera 10 [1]) to see if I can work around enable background since someone decided that they didn’t like that (of course they seem to have neglected to implement the workaround as well), but am still of the opinion that it is sad that web artists have to convert text to pixels in order to make certain cool text effects. 

 

Anyhow, am very interested in having access to path data for text, and have thought some about that recently. The shape of a text-glyph is usually given by its stroke: that that is the geometry is specified by the stroke while what people usually see (since stroke-width defaults to zero) is the glyph’s fill. <text fill=”black” /> being the default color.

 

For purposes of animating and morphing between glyphs, having access, as well, to the “inner-shape” , namely the filled part of the glyph could be very handy as well.  So for example, while “L” might be defined as “M 0,0 L 10,0 10,90 50,90 50,100 0,100 z”, the inner shape of it might just be a path with d= “M 5,5 L 5,95 45,95” and stroke-width=”10”. It seems like the browsers have to do these calculations anyhow to draw the glyph, so exposing that data to authors could simplify our task as authors/programmers/animators a good deal, since a shape with three coordinates is easier to animate than one with six. Likewise given a simple path (such as this one with three nodes) it might be nice to have a method that returns the outline of such a shape, so that it can, in turn, be converted back into a glyph for accessibility purposes. The old ones among you may recall that when I first started lobbying for access to path data, it was because there was no easy way to “top-align” text in SVG since no one seemed to agree on how to measure text [2]. Note: since that time, FF and I seem to have come into agreement about how this should be handled, though IE and Chrome are now goofy.

 

Regards

David

 

[1] http://cs.sru.edu/~ddailey/svg/GeometricAccessibility.html 

[2] http://cs.sru.edu/~ddailey/svg/TopAlignBrowsers.png