1195249 - SVG: Incorrect position of text on textPath when both startOffset and x are specified

Status: RESOLVED INVALID

(Core :: SVG, defect)

Description

[Paul LeBeau]

Attachment: textPath_x_startOffset.svg

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150807085045

Steps to reproduce:

Visit http://jsfiddle.net/u5z02hpx/9/ or load the attached test file into Firefox.


Actual results:

The vertical bar character is positioned at approx half way on the curve.  It should be positioned near the start.


Expected results:

The sample SVG has a <textPath> with a startOffset specified.  The enclosing <text> element has an 'x' specified.

According to the SVG 1.1 (and 2) spec, the 'x' attribute should override the 'startOffset'.

"When the inline-progression-direction is horizontal, then any ‘x’ attributes on ‘text’ or ‘tspan’ elements represent new absolute offsets along the path, thus providing explicit new values for startpoint-on-the-path. Any ‘y’ attributes on ‘text’ or ‘tspan’ elements are ignored."

It appears as if FF is completely ignoring the 'x' attribute.  The paragraph above suggests that the 'x=5' should over-ride the 'startOffset=50%'


Chrome has a similar bug, although it appears to be using a position of (x + startOffset).  IE11 seems to do the right thing.

Comment 1

[Paul LeBeau]

FYI: Chrome bug: https://code.google.com/p/chromium/issues/detail?id=521550

Comment 2

[Gabriela [:gaby2300]]

Seems to work fine using Windows 7 32 bit.
User Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID 20150818030209

Comment 3

[Paul LeBeau]

Attachment: Incorrect rendering in FF40 on Win7_64

Comment 4

[Paul LeBeau]

Attachment: Correct rendering in IE11 on Win7_64

Comment 5

[Paul LeBeau]

I've added a couple of screenshots showing what I think is the incorrect rendering in FF, and the correct rendering on IE11.

Comment 6

[Robert Longson [:longsonr]]

The specification quoted in comment 0 mentions text and tspan and specifically does not mention not textPath. I take that to mean that x does not apply to a <textPath> at all.

If there's inconsistency improved wording in the specification is probably the way to go.

Comment 7

[Paul LeBeau]

The quoted text is from section 10.13.3 "Text on a path layout rules" (SVG 1.1) and is also still present in SVG2 (section 11.8.3). The full text is:

"When the inline-progression-direction is horizontal, then any ‘x’ attributes on ‘text’, ‘tspan’, ‘tref’ or ‘altGlyph’ elements represent new absolute offsets along the path, thus providing explicit new values for startpoint-on-the-path. Any ‘y’ attributes on ‘text’, ‘tspan’, ‘tref’ or ‘altGlyph’ elements are ignored."

Since <textPath> elements can't contain <text> elements, it appears that either it was deliberately included and my interpretation is correct, or it is a mistake and the spec needs fixing.  I will create a spec bug on github to sort out the matter.

Comment 8

[Paul LeBeau]

Spec issue filed: https://github.com/w3c/svgwg/issues/265

Comment 9

[Robert Longson [:longsonr]]

in comment 7 you presumably meant to say textPath is deliberately excluded rather than deliberately included.

Comment 10

[Paul LeBeau]

Actually no.  I was referring to <text> being deliberately included in the list of elements in that paragraph. :)  If it was intentionally included, then the rule seems to say that x overrides startOffset.

Comment 11

[Robert Longson [:longsonr]]

Ahh, I was referring to textPath not being in that list so x does not apply to textPath contents.