RE: Text and Tspan and Anchors - OH MY

Thanks for the feedback.

Good to know its officially being tracked.  I think I had investigated that over a year ago... I loose track.  The odd behavior is that the text gets driven beyond the space it should be contained in for some reason.

SVG 2+ definitely needs to be clearer on what is expected when textLength is applied.  I have an action to help clarify that in the spec, in fact.
So I should revisit where things stand – I had written a test, but never got reconnected to the spec once it moved from mercurial to git.

textLength with <text /> and <tspan /> children really sets up a set of equations with some lengths specified and others variable, and once the full <text /> is specified, the variables are solved for. (maybe not the clearest description)

textLength  is used to specify the overall length, because that is what the SVG 1.1SE spec reads as – regardless of that the intent was.

A textHeight  type analog is also requested at one of the F2F meetings by me, because to use SVG as a replacement for CGM in industry (eg at Boeing for our tens-of-thousands of vector diagrams), we need to have a way of implementing CGM’s “Restricted Text”, which specifies that the given text fills the rectangle  (based on an additional style).

The style specifications have to do with which glyph lines aling at the top and bottom of the text bounding rect (ie what gets driven to textHeight and what sits on the text’s location line; has to do with decenders, Cap Boxed, etc.

Thomas Smailus

From: Amelia Bellamy-Royds [mailto:amelia.bellamy.royds@gmail.com]
Sent: Thursday, March 12, 2015 18:30
To: Smailus, Thomas O
Cc: www-svg
Subject: Re: Text and Tspan and Anchors - OH MY

Thomas:

There are already bug reports for this on the major browsers

Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=890692

Chrome: https://code.google.com/p/chromium/issues/detail?id=375258


Both of these browsers currently do not propagate the textLength adjustments to child <tspan> elements.  The <tspan> content gets rendered at its normal width, and then the rest of the content of the <text> element gets adjusted to meet the final textLength.  Since the only remaining content available to adjust is the whitespace before and after the <tspan>s, that's what gets stretched out.

The total text *does* fill the space, but most of it is filled by stretched-out space characters.

IE stretches things out slightly differently, still exaggerating the whitespace but also stretching the second tspan.  I haven't tested this fiddle, but based on webkit bug reports (https://bugs.webkit.org/show_bug.cgi?id=139210), they also have difficulties with text length adjustments.

In other words, we probably need clearer definitions of the expected behavior, and significant overhauls of implementations.  Part of the problem is that the original purpose of textLength was only as a rendering hint, to control differences between fonts, but everyone wants to use it as a stretch/compress tool.

Also, as a side note, you probably don't want the `xml:space="preserve"` setting.  Although it does not behave like an <pre> element in HTML, it does make sure (in a SVG 1.1 viewer) that each space, tab, or newline character in your code gets reflected as a space in the final text content.  SVG 2 deprecates this in favour of using CSS for whitespace control.

AmeliaBR



From: Smailus, Thomas O
Sent: Thursday, March 12, 2015 16:35
To: www-svg
Subject: Text and Tspan and Anchors - OH MY

I’m curious about what this SVG 1.2se should be rendered as:

The text specifies a location and length, the tspan elements should FILL that extent, yes?
But no, that’s not the case (http://jsfiddle.net/thomassmailus/rxzatmnz/ )