Interaction of x attribute and startOffset in a textPath element.

[BigBadaboom]

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:

<svg xmlns="http://www.w3.org/2000/svg"
        xmlns:xlink="http://www.w3.org/1999/xlink"
        viewBox="0 0 80 80">
    <defs>
        <path id="myTextPath"
              d="M16,40 a24,24 0 0,1 48,0" />
    </defs>

    <path d="M16,40 a24,24 0 0,1 48,0" style="stroke:#600; fill:none"/>

    <text x="5">
        <textPath xlink:href="#myTextPath" startOffset="50%">|</textPath>
    </text>
</svg>

http://jsfiddle.net/u5z02hpx/9/

How should the conflict between the x attribute and the startOffset attribute be resolved?

According to both the 1,.1 and 2 specs:

When the inline-base 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.

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 and text-anchor. So this statement appears to indicate that x should override startOffset. Or at the very least effect it in some way.

Browser interpretation varies:

Firefox: Uses startOffset. x is ignored
Chrome: 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 the x attribute of elements inside a textPath were affected by this rule. In other words, that would now only be <tspan>.

[nikosandronikos]

To add another data point, WebKit behaves as Chrome does.

For history, here's a couple of old discussions on this topic:

• In Linköping we resolved not to add those attributes directly to textPath, partly because they can be specified on the parent text or tspan element.
• Discussed again more recently and I'm a bit confused as to what the outcome was

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.

[karip]

The SVG Text Layout algorithm describes how x, y, dx, dy, rotate and startOffset interact:

• First, the step 6 “Adjust positions: x, y” calculates result.x coordinates for the characters from the x attributes.
• Then, the step 8 “Position on path” calculates the position on path (mid) from result.x and startOffset: “mid is x + advance / 2 + offset”

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:

<text>
    <textPath xlink:href="#myTextPath" startOffset="50%"><tspan x="5">|</tspan></textPath>
</text>

In this case, the SVG2 text algorithm actually treats the x attribute in <text> the same way as in <tspan>. Firefox seems to have a bug if the x attribute is in <text>.

[karip]

I would suggest that browsers implement the SVG Text Layout Algorithm instead of trying to interpret the prose. The algorithm has few issues (I filed #271 and #272), but otherwise it seems to give answers to all questions about svg text positioning.

[Tavmjong]

It should not matter if the 'x' is on the <text> or <tspan>. My interpretation of SVG 1.1 is that both 'x' and 'startOffset' should effect the text position on the path. See last paragraph in https://www.w3.org/TR/SVG/text.html#TextpathLayoutRules

[nikosandronikos]

We resolved on 17 November 2016 that positioning attributes must inherit and the prose will be updated to match the algorithm's behaviour.