W3C home > Mailing lists > Public > www-svg@w3.org > May 2014

RE: Using textLength with tspan children - browsers vary in how they render things.

From: Bogdan Brinza <bbrinza@microsoft.com>
Date: Mon, 19 May 2014 19:11:18 +0000
To: "Smailus, Thomas O" <Thomas.O.Smailus@boeing.com>, David Dailey <ddailey@zoominternet.net>, "www-svg@w3.org" <www-svg@w3.org>
Message-ID: <7b76b7e187a3480eb3aee9305289d858@CH1PR03MB610.namprd03.prod.outlook.com>
Hi Thomas,

I'll file the bug. There is enough information available to make this actionable for our team. Thanks for reporting this!

From: Smailus, Thomas O [mailto:Thomas.O.Smailus@boeing.com]
Sent: Monday, May 19, 2014 10:22 AM
To: David Dailey; www-svg@w3.org
Subject: RE: Using textLength with tspan children - browsers vary in how they render things.

Yeah, that does seem to be the case.

Reading over the SVG 1.1 SE spec it does seem that Microsoft Internet Explorer is not handling it correctly:

For TEXT, the spec  is clear:
The author's computation of the total sum of all of the advance values that correspond to character data within this element, including the advance value on the glyph (horizontal or vertical), the effect of properties 'kerning', 'letter-spacing' and 'word-spacing' and adjustments due to attributes 'dx' and 'dy' on 'tspan' elements.

For TSPAN, the spec addresses what would happen if a tspan and its ancestor (a text in my example) have textLenght specified:
If attribute 'textLength' is specified on a given element and also specified on an ancestor, the adjustments on all character data within this element are controlled by the value of 'textLength' on this element exclusively, with the possible side-effect that the adjustment ratio for the contents of this element might be different than the adjustment ratio used for other content that shares the same ancestor. The user agent must assume that the total advance values for the other content within that ancestor is the difference between the advance value on that ancestor and the advance value for this element.

Now for  TEXT the spec doesn specifically mention descendant elements, only the dx,dy attributes of tspans, but I would have thought the intent would be clear.

Rossen or Bogdan, whats the best way to submit this as a bug report to the Internet Explorer team?

Thomas
--
Thomas Smailus, Ph.D.  P.E.
Boeing Information Technology
thomas.o.smailus@boeing.com<mailto:thomas.o.smailus@boeing.com>

From: David Dailey [mailto:ddailey@zoominternet.net]
Sent: Saturday, May 17, 2014 12:16
To: Smailus, Thomas O; www-svg@w3.org<mailto:www-svg@w3.org>
Subject: RE: Using textLength with tspan children - browsers vary in how they render things.

Hi Thomas,

Firefox seems to be handling much of this now (it was the only way really to make text content scalable!). In 2011 the examples at http://srufaculty.sru.edu/david.dailey/svg/text/
worked about 95% in ASV, 100% in Opera, maybe 25% in Firefox; Chrome and Safari were not really worth mentioning. I didn't play with <tspans> though.

Your experiments are quite informative!

Now Firefox is up to about 60% (handling the textLength and lengthAdjust="spacingAndGlyphs" stuff correctly, but not doing so well on some of the animates and, of course, displacement filter on backgrounds. Opera has fallen back to about 20% (from the previous 100%) and I suppose Chrome is in about the same boat. Apple doesn't let me test in Safari, but I assume it is still pretty awful there for these sorts of things that only artists and aerospace people use;)
ASV holds steady at about 95%.

I would assume that since the FF people seem to have touched this issue relatively recently, that their implementation is pretty trustworthy.

Cheers
David

From: Smailus, Thomas O [mailto:Thomas.O.Smailus@boeing.com]
Sent: Friday, May 16, 2014 6:15 PM
To: www-svg@w3.org<mailto:www-svg@w3.org>
Subject: Using textLength with tspan children - browsers vary in how they render things.

I've been working on a project that requires me to put text in tspan children to a text element, in order to control changes in font/font-size/color, etc for the various fragments.
However, I still need to be able to precisely define how long the text element needs to be via textLength.

In working with IE 11 and Firefox 28, I found that the 2 browsers differ substantially in how they implement the combination of the textLength and the tspan functionality.

I've put together a jsFiddle to illustrate the issue.  Depending on if you view this in IE or Firefox, you get different results:
http://jsfiddle.net/thomassmailus/pUavF/3/

There are 4 examples in the fiddle, from top to bottom

1.       textLength is specified as an attribute of the text element, the various text are all in tspan children of the text

2.       textLength is not in the text element, but in the first tspan child.

3.       No textLength specified at all (for reference only)

4.       PNG raster of what I am hoping is the target implementation when case #1 is the specification

a.       The textLength is specified as attribute to <text />

b.      The various <tspan /> children to text as a whole, fill up the extent defined by the textLength in the parent <text /> element.


It appears Firefox 28 implements the desired functionality.
What we see is that IE and FF differ in how they implement the effect whein tspan and textLength are used in a <text /> element - the result is thus not at all consistant and a problem for authors.

What are the thoughts of the community on expected behavior?


Thomas
--
Thomas Smailus, Ph.D.  P.E.
Boeing Information Technology
thomas.o.smailus@boeing.com<mailto:thomas.o.smailus@boeing.com>
Received on Monday, 19 May 2014 19:11:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:53 UTC