1005452 - SVG text-anchor bug

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Thomash Lee]

Attachment: test.svg

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20140314220517

Steps to reproduce:

1. Open the attached SVG file in any Mozilla browser.
2. Text of the lines 2, 4 and 6 do not align correctly due to the bug described below.


Actual results:

Mozilla handles SVG text space differently than the W3 SVG specification. If you leave a line break after the tspan closing tag before another tspan opening tag, Mozilla treats this line break as an extra space for the previous text of the tspan element if the xml:link property is defined as "default". This creates an issue for tspan or text element with text-anchor property defined "middle" or "end" in that Mozilla align the text taking account to the last extra space caused by the line break between the closing and opening tspan tags.

Although changing xml:space to "preserve" solves the above problem, this creates another issue that if the tspan element is nested within another tspan element, the inside text misaligned even greater.

This issue must be addressed because a, it does not conform the W3 SVG specification and b, the reindentation of XML editor creates line break and space/tab for any new descendant element which means the line breaks among tspan elements is inevitable in most cases. Therefore it is Mozilla's obligation to fix the handling of space instead of requiring users to revise their SVG codes in order to look properly in Mozilla browser.


Expected results:

Text of the lines 2, 4 and 6 should align exactly like lines 1, 3, and 5.

Comment 1

[Robert Longson [:longsonr]]

There's no crash just rendering differences so not security sensitive.

Comment 2

[Robert Longson [:longsonr]]

We display all the testcases the same as Opera and IE 9 except for the last one where all three display something differently.

Comment 3

[Robert Longson [:longsonr]]

> If you leave a line break after the tspan closing tag before another tspan opening tag, Mozilla treats > this line break as an extra space for the previous text of the tspan element if the xml:link property > is defined as "default".

This is as it should be. With default whitespace is compressed to a single space (unless it occurs at the beginning or end of the text as a whole when it is removed altogether). I don't think this is a bug.

The xml:space=preserve issue (the last line in the testcase) is strangely drawn though. I think that is a bug.

Comment 4

[Thomash Lee]

Attachment: "Colour" example

Comment 5

[Thomash Lee]

Comment on attachment 8416972 [details]
"Colour" example

(In reply to Robert Longson from comment #3)
> > If you leave a line break after the tspan closing tag before another tspan opening tag, Mozilla treats > this line break as an extra space for the previous text of the tspan element if the xml:link property > is defined as "default".
> 
> This is as it should be. With default whitespace is compressed to a single
> space (unless it occurs at the beginning or end of the text as a whole when
> it is removed altogether). I don't think this is a bug.

There is the instance that you change the style of a particular alphabet in a word like this:
<text><tspan fill="red>C</tspan><tspan fill="orange">o</tspan><tspan fill="yellow>l</tspan><tspan fill="green">o</tspan><tspan fill="blue>u</tspan><tspan fill="purple">r</tspan></text>

After reindentation it becomes this:
<text>
 <tspan fill="red>C</tspan>
 <tspan fill="orange">o</tspan>
 <tspan fill="yellow>l</tspan>
 <tspan fill="green">o</tspan>
 <tspan fill="blue>u</tspan>
 <tspan fill="purple">r</tspan>
</text>
And then the whole word "Colour" is ripped apart and becomes "C o l o u r" in Mozilla browser (see 2nd attachment). This does not happen with librsvg/RSVG.

Comment 6

[Thomash Lee]

Sorry I made the wrong comment. The "Colour" example also behaves the same in librsvg. But again, librsvg does not take the space caused by line break/indent into account when aligning the tspan text to middle or end.

Comment 7

[Robert Longson [:longsonr]]

> And then the whole word "Colour" is ripped apart and becomes "C o l o u r"
> in Mozilla browser (see 2nd attachment). This does not happen with
> librsvg/RSVG.

That "ripping apart" is correct per specification. Whitespace will get rendered in SVG. You should disable whatever is doing reindentation.

Comment 8

[Cameron McCormack (:heycam)]

I replied to an off-bug email, but I'll include my reply here too:

> [regarding XML editor reindentation of the markup causing rendering differences]

As in HTML, white space within text content is significant.  The spaces
that appear in the rendering between each letter when you have the white
space in the markup between each <tspan> is correct.  For some XML-based
languages changing the white space in the document so that the tags are
indented nicely is an operation that doesn't change the meaning of the
document, but it's not a safe assumption for all XML-based languages.

> [regarding the anchoring including the white space at the end of "middle"]

To explain the behaviour you are seeing:

When you have a <text> element that has more than one character with an
absolute position assigned to it (as you have in this example with the
x="" attributes on the two child <tspan>s), then each absolute position
begins a new "text chunk", as SVG 1.1 describes it.  So for this:

  <text text-anchor="middle">
    <tspan x="200" y="60">middle</tspan>
    <tspan x="200" dy="1200">n</tspan>
  </text>

because we're operating in the xml:space="default" mode, we will trim
the leading and trailing white space of the entire <text> element and
then collapse multiple white space characters into a single space.
Effectively, we will have these characters and x positions:

  'm' at x=200
  'i'
  'd'
  'd'
  'l'
  'e'
  ' '
  'n' at x=200

There are two text chunks to which anchoring is applied: "middle " and
"n".  The space character remains in that first text chunk since we do
start/end trimming of white space on the whole <text> element, not each
text chunk within it.

Since we still need to render the space character after the 'e' (well,
there is no glyph but you can still select the space character with the
mouse) I think it makes sense to include it when calculating the width
of the entire chunk that is then anchored.

Comment 9

[Cameron McCormack (:heycam)]

longsonr pointed out to me that the last "middle" line of that test case is wrong, and I agree, but with a different expected rendering than he expects.

Since it is xml:space="preserve", it shouldn't be centred.  If you select all in the document, you can see the white space characters to the right of the "middle".  That contiguous selected block should be centred on the line.

Comment 10

[Thomash Lee]

Since you guys insist these behaviors to be correct, I got to admit that the reason I made this report is that my SVG files are mostly contributed to Wikimedia and it uses librsvg to render SVG to PNG raster image. While it could be librsvg misinterpreted the W3 specification, I would say Wikimedia has contributed the prevalence of SVG considerably, if not tremendously. Therefore, I hope the W3 or Mozilla developers can use their influence to ask the librsvg developer to adhere to the "common" practice of SVG text handling.

As for the "colour" example, I deduce that Inkscape removes the space because every SVG source opened by it are automatically reindented (I don't think the user has any option to turn it off). If Inkscape follows the W3 specification exactly, the unintended white-space between glyphs will be irremovable (as in the case of giving a line of consecutive glyphs different styles). So I still think W3 has some responsibility to how XML indentation style affected SVG tspan instead of telling user to avoid reindentation whatsoever. It is not always under our control.

Comment 11

[PRO]

(In reply to Robert Longson from comment #7)
> > And then the whole word "Colour" is ripped apart and becomes "C o l o u r"
> > in Mozilla browser (see 2nd attachment). This does not happen with
> > librsvg/RSVG.
> 
> That "ripping apart" is correct per specification. Whitespace will get
> rendered in SVG. You should disable whatever is doing reindentation.

OK, IMO that is exactly what is not intended from the W3C specification, it is exact twisted. As you can see Mozilla don't pass the W3C SVG test case "xml:space": http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlSVGWeb/text-ws-02-t.html
> http://www.w3.org/TR/SVG11/text.html#WhiteSpace

Mozilla remove the line-break on "preserve" and set a whitespace on default. (I don't know another SVG render which do this. Anyway my Chrome(35) IE(9) don't interpret "xml:space".)

I put attached files together on the libRSVG server: https://commons.wikimedia.org/wiki/File:SVG_test_text_tspan_ws.svg (last color example)

Comment 12

[Cameron McCormack (:heycam)]

(In reply to PRO from comment #11)
> OK, IMO that is exactly what is not intended from the W3C specification, it
> is exact twisted. As you can see Mozilla don't pass the W3C SVG test case
> "xml:space":
> http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlSVGWeb/text-ws-02-t.
> html
> > http://www.w3.org/TR/SVG11/text.html#WhiteSpace

I could have sworn the behaviour of xml:space="preserve" was to drop newlines rather than turn them into space characters.  I must have misread.  (It's definitely the behaviour for xml:space="default".)  I've filed bug 1019555 for this.

This doesn't affect the "reindentation - default" case in attachment 8416972 [details], though, where the white space only text nodes between each <tspan> still should contribute to the rendering.

Comment 13

[Cameron McCormack (:heycam)]

(In reply to Cameron McCormack (:heycam) from comment #9)
> Since it is xml:space="preserve", it shouldn't be centred.  If you select
> all in the document, you can see the white space characters to the right of
> the "middle".  That contiguous selected block should be centred on the line.

This part will be fixed by my forthcoming patch on bug 1019555, too.

Comment 14

[PRO]

Good to hear this all. I must correct me too, Chrome 35 now support xml:space (I would sworn 34 not, so he pass the W3C test).
Let's keep doing more SVG.

(For sure thats not the last bug report of the Wikimedia community, unfortunately "the own" libRSVG is very bad with very bad support)
Best regards

Comment 15

[Robert Longson [:longsonr]]

I don't think there's anything left that's valid in this bug. Whatever there was bug 1019555 fixed. If Inkscape messes around with whitespace in a way that affects rendering then file a bug on it.