textPath method="stretch"

This is second post of this mail. For some reason line breaks were not respected on the first time.
Hopefully it will be sent correctly this time.

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 is
1) 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 Opera
implementation: "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 linearity
and 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 textPath
hence 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/

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 regards
Israel