Closed
Bug 1195249
Opened 9 years ago
Closed 8 years ago
SVG: Incorrect position of text on textPath when both startOffset and x are specified
Categories
(Core :: SVG, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: paul.lebeau, Unassigned)
Details
Attachments
(3 files)
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.
Reporter | ||
Comment 1•9 years ago
|
||
FYI: Chrome bug: https://code.google.com/p/chromium/issues/detail?id=521550
Updated•9 years ago
|
Component: Untriaged → SVG
Product: Firefox → Core
Comment 2•9 years ago
|
||
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
Reporter | ||
Comment 3•9 years ago
|
||
Reporter | ||
Comment 4•9 years ago
|
||
Reporter | ||
Comment 5•9 years ago
|
||
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•8 years ago
|
||
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.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 7•8 years ago
|
||
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.
Reporter | ||
Comment 8•8 years ago
|
||
Spec issue filed: https://github.com/w3c/svgwg/issues/265
Comment 9•8 years ago
|
||
in comment 7 you presumably meant to say textPath is deliberately excluded rather than deliberately included.
Reporter | ||
Comment 10•8 years ago
|
||
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•8 years ago
|
||
Ahh, I was referring to textPath not being in that list so x does not apply to textPath contents.
You need to log in
before you can comment on or make changes to this bug.
Description
•