Add 'textLength' attribute to <svg:tspan> elements in SVG export

[sailingKieler]

SVG exports of diagrams suffer (and will always suffer) from the different text renderings on different machines, and worse, even in different browsers on the same machine.

I just figured out that the SVG elements <text> and <tspan> offer the attributes textLength and lengthAdjust, which I wasn't aware of. See also https://codepen.io/tigt/post/more-robust-svg-text-with-lengthadjust-and-font-size-adjust

Hence, it would be valuable to add the designated textLength value to the generated SVG output and check whether that improves the portability of SVG exports.

[NiklasRentzCAU]

I also already had this problem when implementing the rendering of KText elements for the Sprotty-based viewer of KLighD. For that platform, I implemented the SVG rendering with that attribute here as well, however, I found out that also may cause a slightly inconsistent look between glyphs in different texts on other platforms not natively supporting the font. A solution for optimal consistency would be to only use open and free-to-use fonts and include them in the viewer and the SVGs directly.

If you find another solution that preserves the texts in the SVG (not rasterizing them or converting them to paths), please let me know.

[sailingKieler]

I found out that also may cause a slightly inconsistent look between glyphs in different texts on other platforms not natively supporting the font

That's for sure, but we're hopefully getting closer...

If you find another solution that preserves the texts in the SVG (not rasterizing them or converting them to paths), please let me know.

Ok, but I guess that will never happen :-/

[sailingKieler]

I did some experiments with the generation of the textLength attribute for <tspan> elements.
Sadly Chromium messes up the rendering for multi <tspan> texts, at least for me in version 83.0.4103.116 on OSX:

more precisely only the last <tspan> element in the row seems to apply the textLength property properly.
(here with font Monaco (OSX, monospace), the first one is added without the textLength property as reference)

This seems to be documented here: https://bugs.chromium.org/p/chromium/issues/detail?id=375258

Consequence: I'm thinking about dropping the <tspan> approach and generating a group of <text> elements

[sailingKieler]

Btw. Firefox seem to not handle textLength for nested <tspan>s at all.

[NiklasRentzCAU]

This is exactly why I also opted to only use <text> and no <tspan>s in the Sprotty implementation. Again, I suggest looking at my implementation linked above, as it handles exactly this problem as well.

[sailingKieler]

Again, I suggest looking at my implementation linked above, as it handles exactly this problem as well.

Unfortunately, that's only partly helpful. On the one hand I'm not trained in reading tsx, and the freeHEP SVG builder has its own sophistications on the other hand. Thanks anyway ;-)

[sailingKieler]

With the changes listed above the generated SVG is

[sailingKieler]

@NiklasRentzCAU, @soerendomroes we can close this, right?

[NiklasRentzCAU]

Yes, the PR for this issue is merged into master and we did not notics any further problems regarding this issue.
Closing now.