Bug 112032 – SVG rendering ignores xml:space="preserve" attribute for text

• Status: RESOLVED
• Resolution: FIXED
• Component: SVG

[Peter Boström]

Rendering a SVG file which contains multiple spaces inside text, and the xml:space="preserve" attribute will will still compact space characters. (Acting like xml:space="default".)

I think the offending line is in RenderSVGInlineText::RenderSVGInlineText on line 69 in chromium/src/third_party/WebKit/Source/WebCore/rendering/svg/RenderSVGInlineText.cpp, but I am overall unfamiliar with the WebRTC code base. The constructor for RenderSVGInlineText strips additional whitespace regardless of this tag.

Attaching screenshot of this bug in Chromium, using WebKit 537.32 (trunk@143310), and expected result as rendered inside Firefox.

[Peter Boström]

Created attachment 192477 [details]
Screenshot of render error

[Peter Boström]

Created attachment 192478 [details]
Example SVG file

[Arty]

It seems that xml:space attribute is simply not inherited. In your example SVG file this attribute is specified on the enclosing text tag and it does not work. If you specify this attribute directly in the tspan tag, the white space will be preserved. This is clearly a bug as xml:space attribute should be inheritable according to section 10.15 of the Scalable Vector Graphics (SVG) 1.1 (Second Edition) specification.

[Said Abou-Hallawa]

Here is a simpler test case.

Open the following SVG in WebKit:

<svg xmlns="http://www.w3.org/2000/svg" version="1.1"
     font-family="monospace" font-size="20" xml:space="preserve">

  <text x="30" y="50">                                         Hello             there</text>
  <text x="30" y="100">Hello there</text>

</svg>

Result: The two lines of text are aligned vertically with one space between the two words in each of them.
Expected: The leading spaces in the first line should shift the display position of the word "Hello". Also the spaces between the word "Hello" and the word "there" of the first line should be persevered.

[Said Abou-Hallawa]

Created attachment 242682 [details]
Simpler test case

[Radar WebKit Bug Importer]

<rdar://problem/19164263>

[EWS]

Committed 255917@main (40db7d1db402): <https://commits.webkit.org/255917@main>

Reviewed commits have been landed. Closing PR #5670 and removing active labels.

[Ahmad Saleem]

*** Bug 149665 has been marked as a duplicate of this bug. ***

[Tim Nguyen (:ntim)]

Bug 250603 will revert this change due to a regression on wsj.com

[Ahmad Saleem]

(In reply to Tim Nguyen (:ntim) from comment #9)
> Bug 250603 will revert this change due to a regression on wsj.com

Do we have web page where I can test locally whether this is something on our end or wsj.com end and why this is not reproducible in Chrome, which has this patch.

[EWS]

Committed 281364@main (e4359d3e33a4): <https://commits.webkit.org/281364@main>

Reviewed commits have been landed. Closing PR #31060 and removing active labels.