-
Notifications
You must be signed in to change notification settings - Fork 134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interaction of x
attribute and startOffset
in a textPath element.
#265
Comments
To add another data point, WebKit behaves as Chrome does. For history, here's a couple of old discussions on this topic:
My opinion is that x and y on the parent element should have no effect on where the text lies along the path for a textPath, because only relative adjustments make sense. If I were to do anything I would have it move the start point of the path, but that would break the mapping of co-ordinates to glyphs. |
The SVG Text Layout algorithm describes how x, y, dx, dy, rotate and startOffset interact:
So, x and startOffset (both) should affect the position of text on text path. Firefox gives the same result as Chrome and Webkit if the x attribute is moved to a tspan:
In this case, the SVG2 text algorithm actually treats the x attribute in |
It should not matter if the 'x' is on the |
We resolved on 17 November 2016 that positioning attributes must inherit and the prose will be updated to match the algorithm's behaviour. |
Relevant spec section: https://svgwg.org/svg2-draft/single-page.html#text-TextpathLayoutRules
See also the following bug I reported to FF: https://bugzilla.mozilla.org/show_bug.cgi?id=1195249
And an email to the mailing list last year: https://lists.w3.org/Archives/Public/www-svg/2015Aug/0007.html
Consider the following file:
http://jsfiddle.net/u5z02hpx/9/
How should the conflict between the
x
attribute and thestartOffset
attribute be resolved?According to both the 1,.1 and 2 specs:
SVG 1.1 also included tref and altGlyph in the list of elements included in this paragraph.
"startpoint-on-the-path" is calculated from
startOffset
andtext-anchor
. So this statement appears to indicate thatx
should overridestartOffset
. Or at the very least effect it in some way.Browser interpretation varies:
Firefox: Uses
startOffset
.x
is ignoredChrome: seems to be calculating
x + startOffset
IE: Uses
x
.startOffset
is ignored.We should clarify the correct interpretation. I am wondering if the inclusion of the
<text>
element in the above copy was originally a mistake. Since<text>
are not valid inside a<textPath>
, perhaps it was the intention that only thex
attribute of elements inside a textPath were affected by this rule. In other words, that would now only be<tspan>
.The text was updated successfully, but these errors were encountered: