textPath method="stretch"

Hi All,
Doug:>>>Opera does implement it, and it's cool!>>>   http://schepers.cc/svg/textPath-stretch.svg
Alex:>>Finally... Now I know what that means for all the other implementers.
David:>With implementation of so much of the text stuff being spotty, and with the>spec being complex it is hard to know what might do what.
I agree with David and this is a proposal to make the description of the textPath 'stretch' method less ambiguous.
For convenience here is the essence of the spec, word by word, for method="stretch":
"...the glyph outlines will be converted into paths, and then all end points and control points will be adjusted to be along the perpendicular vectors from the path..."
Say I am an implementer. I clearly know what are "all end points and control points"and I clearly know what are the "perpendicular vectors from the path" so it is clear that those points must lie on these vectors. What I still don't know is1) Where along the vectors? what distance from the curve.2) Where should I put all the points which are *not* end/control points?    One thing is clearly implied: if I do not put the other points also on their perpendicular  vectors, the new paths will not be continuous and certainly not the spec intention so  from now on I must consider "all end points and control points" as just "all points".  Still, no answer to (1).
Now, consider 3 implementers.
Implementer #1 - Opera. If I may try to put in spec words what is obvious in Operaimplementation: "Points are adjusted such that all horizontal straight lines preserve co/linearity and are parallel to the curve tangent touching the mid-point of the glyph base". (example linear is the horizontal midline of A and colinear are its 2 legs base-lines).
Implementer #2 Largely agree with Opera except one subtle difference - the colinearity constrain: multiple base/cap lines (A,W,X etc.) will not be colinear but independently linear.Change in wording is thus also subtle:"...all horizontal straight lines preserve linearityand are parallel to the curve tangent touching their mid point."
Implementer #3 Think it's much more simple: "points will be adjusted" must also imply "to be in their original position" and together with "along the perpendicular vectors from the path" makes perfect sense that the meaning of the spec is mapping from the glyphs space to the textPath curved space point by point. "align" treat glyphs like solids, "stretch" should treat glyphs like rubber. Whatever "align" is doing to the glyph-midline<http://www.w3.org/TR/SVG/text.html#GlyphMidline>"stretch" should apply to *all* the glyph vertical lines.In spec words: "all points will be adjusted to be along the perpendicular vectors from the path, preserving vertical distance from the path."
Last interpretation practically maps horizontal straight lines to offset curves of the textPathhence will be referenced as "offset-mapping". In particular, base-lines of the glyphs are mapped to the textPath skeleton.
The problem: three different looking implementations, all confirm to the spec.
In order to eliminate the ambiguity, I propose to change the wording of the spec. Question is, to what. Which of the above interpretations (and there could be more)best describe the meaning of the spec.
Personally, I'm convinced that the meaning of the spec is offset-mapping and can just try to strengthen my conviction by bringing Alex response to David:(English is not my first language and if Alex response does not imply what I assume it does, my sincere apologies for taking the liberty to quote him)
David:>>Currently in aligning text to a (baseline) curve in SVG, the characters are never distorted, >>merely positioned and rotated. 
Alex:>Actually since SVG 1.0 there has been an attribute 'method' on <textPath> when set to 'stretch' is>supposed to do most of what you describe here.
Indeed, implementing 'stretch' as offset-mapping, does create the subset of all lines stretched-to-fit a baseline curve, thus describing a significant part of David text aligning proposals.  
In case the proposal to change the description of the "stretch" spec is not accepted, I propose a new value: method="stretchToFit/offset/....." and use the above offset-mapping to describe it.

Cameron:>I like and want to have support for this effect...I’d like to see someone prototype it in JavaScript...(To be accurate, this comment is on dual-curve-fitting, which demos follow later.) http://owl3d.com/svg/tests/boundText/circle_text.svg
Single 'B' written to the entire circumference:http://owl3d.com/svg/tests/boundText/circle_text_B.svg
Next demo requires text/glyph scaling prior to stretch.Glyphs aspect ratio (y/x) of 6:http://owl3d.com/svg/tests/boundText/circle_text_ar6.svg
I think next demo is off the scope of current SVG methods,it's included for a possible future consideration.Graduated aspect ratio 0.25 to 1:http://owl3d.com/svg/tests/boundText/circle_text_var.svg
Use cases:Beyond the artistic value of an offset-mapping to text, I think it will make many long forgotten use-cases to be revisited. 
GIS. So far, a railroad written to a curved textPath would show up broken, which naturally made the designer abandon the idea on first try. Now she might reconsider:<http://owl3d.com/svg/tests/boundText/railroad.svg>Streets "written" with a single cross-section glyph (side-walk, parking, separation-line etc.), elevation figures on contours, fancy border lines between districts and the text written to them, I think all those use-cases will be revisited. 
Markers as glyphs. So far, such markers could be written perpendicular to a textPath and to precise locations (startOffset). Now, they will also adapt their curvature to the textPath.
I think two combined features will be irresistible for designers:1) Entire path inherits curvature characteristics of another path.    English: smear any design on any path outline.2) Seamless connections. Emphasized in the spec as distinct feature     of "stretch" (which cannot be achieved unless at least the two vertical  borders of each glyph are offset-mapped).

Rest of the demos are for other combinations of text-fit-to-curve/s suggested by David, but are definitely not an integral part of the "stretch" proposal.It's just so naturally self-requested next-step, that I include them in this post:
In the same folder: http://owl3d.com/svg/tests/boundText/Pages:top_in.svg ; top_out.svg ; 2curves.svg ; 2curves_B.svg
Note the difference between 2curves demos and the silverlight example at<http://wsmithdesign.wordpress.com/2010/05/26/silverlight-text-effects/>which keeps base/cap lines linear.
Cameron:>(You could do it with a displacement map, but transforming the vectors>would be preferable.) 
All demos made with only vector manipulations (and only JS+SVGFont).
Last words are thanks: without Opera taking the 'stretch' challenge, most likely this conversation would not take place.
Comments are welcome and in particular I would appreciate comments from Opera.
Best regardsIsrael