Does Prince support the textLength property: https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/textLength? And if not is it possible to add support?

Here is a basic example: https://jsfiddle.net/daneren2005/Lrq9wud4/6/. It is applied to both the tspan and the text nodes because FF only works with it on the text node and Chrome only works with it on the tspan. They don't seem to conflict having the properties on both. I would like to start using this property but I wanted to be sure it wasn't a dead end before wasting a bunch of time coding it.

Prince doesn't support this property yet. We might add it in the future, but probably not for Prince 12.

Today we have an updated latest build of Prince that supports the textLength attribute in SVG, it took a lot of work!

Prince allows 'textLength' to be specified on an element and also on an ancestor of that element. As far as I know, no other SVG implementation implements that yet.

A known issue: if the text content on an element with 'textLength' is split into multiple text chunks (e.g. by specifying absolute position adjustments though 'x' or 'y' attributes) then the 'textLength' value will incorrectly be applied to each text chunk individually.

I am getting an interesting issue that might be related to the issue you mentioned above. I do a single text node for each line of text with multiple tspans for the different styled chunks. ie: "Test this out" with only the this bolded, it would be

<text><tspan>Test </tspan><tspan bold-styling>this</tspan><tspan> out</tspan></text>

.

For Firefox you have to put the textLength on the text node for it to work. In Chrome you have to put the textLength on each tspan node. Neither one seem to interfere with each other, so I actually just put the textLength on both the text node and each tspan node inside of it. It's one of those things that seems like it shouldn't work but in practice makes all browsers that I know of work correctly. Prince actually makes each individual tspan inside of it the size of textLength when you do that instead of making the entire text node that width. I did notice that if I remove the textLength on each of the tspans it works correctly though.

That example consists only of a single text chunk (a term defined in SVG) so it's not the issue I mentioned. If you add textLength on both the text and tspan elements, e.g.

<text textLength="80">
  <tspan textLength="20">Test </tspan>
  <tspan textLength="20" bold-styling>this</tspan>
  <tspan textLength="20"> out</tspan>
</text>

then each text run ("Test ", "this ", " out") will be expanded/compressed to be 20 units long, and the text as a whole to be 80 units long.

Firefox only supports textLength on the <text> element so overall the text will be 80 units long but the individual text runs are not adjusted. https://bugzilla.mozilla.org/show_bug.cgi?id=890692

Chrome seems to take the textLength value from the first <tspan> to adjust the whole text content.

Inkscape behaves like Firefox (in this instance).
Batik behaves like Chrome (in this instance).

Ah and I guess I am just putting textLength="80" on every single tspan since that is what makes Chrome and FF work correctly:

<text textLength="80">
  <tspan textLength="80">Test </tspan>
  <tspan textLength="80" bold-styling>this</tspan>
  <tspan textLength="80"> out</tspan>
</text>

I actually didn't know that Chrome was only taking the textLength from the first tspan and not each individual tspan. That is good info to know.