X coordinates of tspan elements: Issues in generation and rendering
Briefly: Certain text elements created within Inkscape may not have their X-positions correctly recorded in the SVG.
This issue can be worked around by nudging the element to force a "coordinate rewrite". However, (1) that is not always possible and (2) it's much better if extensions can work correctly without forcing the user to nudge parts first.
This behavior appears to be present in both 0.91, 0.92 and 1.0a.
Creating a piece of text with inconsistent position
A test file ("centering_trivial.svg") is included as an attachment. To create your own file reproducing the issue, here are the steps, starting with a new file.
- Use the text tool to create two lines of plain (not flowed) text.
- While the issue is presumably present in one line, it's very hard to observe changes to left-center-right alignment with only a single line.
- Choose the regular cursor ("Select and transform objects") tool from the toolbar to exit text editing. This should leave the text element selected.
- Take care to not bump or move the text element.
- The block of text itself should be selected, not the text within the element.
- With that text element still selected, choose the text tool from the toolbar.
- From the controls bar (which may have a better name) click the button to align the text right. The tool tip for the button is "Align Right" in 0.91.
- Save the file
The SVG file contents
Opening the test file ("centering_trivial.svg") or looking in the XML editor, one finds the following (slightly abridged):
<text id="text6350"
y="141.59245"
x="177.43713"
style="[...]" xml:space="preserve">
<tspan style="[...]" id="tspan6338"
y="141.59245"
x="128.06033"
sodipodi:role="line">A Simple But Strenuous Test of Text Alignment </tspan>
<tspan style="[...]" id="tspan6340"
y="148.31288"
x="128.06033"
sodipodi:role="line">w/2 lines.</tspan> </text>
The text
element has two tspan
subelements. Each has its own x coordinate value.
Results after nudging:
If you either (1) cut and paste-in-place the text element or (2) nudge it up and down by a pixel, the text element is visually unchanged, but the XML looks quite different (further abridged):
<text
y="141.59244"
x="177.43748">
<tspan
y="141.59244"
x="177.43748"
>A Simple But Strenuous Test of Text Alignment </tspan>
<tspan
y="148.31288"
x="177.43748"
>w/2 lines.</tspan> </text>
If you'll notice, the X positions of the tspan
elements have changed (from ~128 to ~177.4, the value of the container text
element), even though there is no visual change to the document.
A copy of this file after nudging, "centering_trivial_out.svg", is included in the attachments.
Analysis:
Per the SVG spec, one should expect the x and y coordinates in a tspan
element to dictate where it is positioned on the page. That does appear to be the case after "nudging" the element. So, let us regard the behavior after nudging as the more "correct" behavior.
Prior to nudging it looks like there are two separate issues at work here:
-
The
tspan
elements, as created by this process, do not initially have the correct coordinates. They are fixed after nudging only. It seems to me that this is a bug and should be fixed. -
The
tspan
elements, as initially created (with the "bad" x-values), are not being displayed correctly. Inkscape appears to instead display thesetspan
elements using the x-coordinate from the parenttext
element, even prior to updating thetspan
value. In practice, Inkscape is rendering different graphics than are available through the SVG tree. While this may be somewhat "desirable" since it hides issue 1, my impression from the SVG spec is that it is not correct behavior. (SVG created in another application may well behave incorrectly when imported because of this.)
Consequences:
While this has been around for a long time (again, since at least 0.91), I'm running into issues now with a new extension that uses the position of text. ( oskay/hershey-text#7 , extensions#64 (comment 166319118) ) Since Inkscape appears to be rendering something different than is actually present in the SVG file, the consequence is that the new extension appears to generate incorrect output.
We can potentially work around this in extensions, by ignore the x-coordinate of tspan
elements. However, since there does appear to be incorrect behavior on Inkscape's part, it would be preferable to fix that than to work around it.