Re: Supporting an option deforming algorithm for <textPath>?

For the issue relating to cursive scripts, the original specifications did
consider the situation.  There is an attribute to indicate whether letters
should be stretched rather than aligned individually:

   - http://www.w3.org/TR/SVG11/text.html#TextPathElementMethodAttribute

Unfortunately, this has not been implemented in web browsers, in part
because there were no clear guidelines on how to do so & in part because it
would require novel transformations not implemented elsewhere.  As Paul
notes, the detailed implementation notes focus on the one-glyph-at-a-time
alignment.

Compounding this, most browsers treat every character in a textPath as an
independent layout chunk, and do not even apply bi-directional re-ordering
or substitute required ligatures and proper glyphs based on the position
within a word.  The chromium bug report for that is here:

   - https://code.google.com/p/chromium/issues/detail?id=374526
   - http://fiddle.jshell.net/fejcxt39/1/

The second link is a JS Fiddle version of the test case created for that
bug report. Firefox renders it correctly, Chrome & IE don't.

Nonetheless, even on Firefox things look wonky when the path curves,
because then individual glyphs get broken apart, as the third sample in
this modified version of the fiddle shows:

   - http://fiddle.jshell.net/fejcxt39/3/

So, to address Paul's original question:

> Should the idea of adding a new alternative algorithm be considered?
> Perhaps one that specifies glyph deformation rather than simple rotation?
>

 Yes, it should, in that the specs should give better guidelines about how
to implement the attribute that is already there (and also how to handle
bi-directionality on a textPath).  It's on my personal to-do list to look
at this summer, but if anyone else is interested or already working on it,
please let me know!

However, as I mentioned, stretching text on a path -- and also the more
artistic dual-curve alignments described in David's link -- require
graphical transformations that don't currently exist elsewhere in SVG.
There have been other debates on this list about the usefulness of having
these non-affine transformations [1], and the use cases go well beyond
text.  However, it is also a very complex topic, and we wouldn't want to
address it quickly only to find that the approach used is unnecessarily
restrictive or difficult to implement.

That doesn't mean that we can't address <textPath method="stretch"> now.
It just means that we would want to do so carefully so that browser
implementations could eventually extend their implementations to other
non-affine transformations.

Best,
Amelia Bellamy-Royds

[1]: https://lists.w3.org/Archives/Public/www-svg/2014Nov/0041.html and
subsequent