1055968 - SVG Text on a path is broken

Status: RESOLVED WORKSFORME

(Core :: SVG, defect)

Description

[Tavmjong Bah]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0 (Beta/Release)
Build ID: 20140819030202

Steps to reproduce:

Displayed SVG with text on path.


Actual results:

Text missing.


Expected results:

Displayed text.

Here is an example where text is displayed, but displayed incorrectly:

http://www.w3.org/TR/SVG/images/text/toap01.svg

For correct display see:

http://www.w3.org/TR/SVG/text.html#TextPathElement

This is a regression as this worked in the past.

Comment 1

[Robert Longson [:longsonr]]

There are plenty of paths that do work so I wonder what's special about this one?

Comment 2

[Alice0775 White]

Regression window(m-i)
Good:
https://hg.mozilla.org/integration/mozilla-inbound/rev/26d8874e7fdc
Mozilla/5.0 (X11; Linux i686; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140801091216
Bad:
https://hg.mozilla.org/integration/mozilla-inbound/rev/f8785a729a51
Mozilla/5.0 (X11; Linux i686; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140801091420
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=26d8874e7fdc&tochange=f8785a729a51

Triggered by:
150cdebe837f	Bas Schouten — Bug 1039568: Add a capture DrawTarget to Moz2D. r=jrmuizel

Comment 3

[Alice0775 White]

[Tracking Requested - why for this release]:

Comment 4

[Alice0775 White]

This seemed to be fixed in Latest Nightly34.0a1.

Reporter,  could you please confirm ?

Comment 5

[Tavmjong Bah]

Yes, the test file (http://www.w3.org/TR/SVG/images/text/toap01.svg) now displays correctly. Thanks!

My file that triggered this bug report still does not work; it appears that a script is messing things up and this bug was a red herring. Argh. While investigating this, I id noticed that the 'x' attribute on the text element is being ignored. According to the SVG spec (last paragraph of 10.13.3 in SVG 1.1 Second Edition) an 'x' attribute on horizontal <text>, ... represents a new absolute offset along the path. It is not 100% clear how this melds with 'startOffset' but Chrome adds the 'x' value to the 'startOffset' value in order to position the text, which seems to be reasonable thing to do. I guess this should be opened as a different bug.

Comment 6

[Robert Longson [:longsonr]]

Please raise a new bug for the x + startOffset issue.

Comment 7

[Robert Longson [:longsonr]]

bug 1068603 fixes this

Comment 8

[Daniel Holbert [:dholbert]]

(In reply to Robert Longson from comment #7)
> bug 1068603 fixes this

Are you sure?

(If so: which part of this bug does bug 1068603 fix? It sounds like the original bug was really fixed back in September, per comment 4 / comment 5.  And the residual x/startOffset issue didn't sound like it would've been affected by bug 1068603, unless it happened to require "C" path commands for straight lines.)

(Having said that: from local testing, I *can* confirm that text-on-a-path didn't draw at all for straight-line "C" commands like in d="M0,100 C100,100 150,100 200,100" in yesterday's nightly, and draws correctly in today's nightly.  So that scenario was broken & was fixed by bug 1068603.  I'm just not sure that's part of this bug here.)

Comment 9

[Robert Longson [:longsonr]]

Doesn't work on Firefox 34 for me, does on trunk. The startOffset issue should be separated into a different bug per comment 6.

Comment 10

[Daniel Holbert [:dholbert]]

Ah -- I can confirm this is broken in Firefox 34 (text zig-zags instead of curving).  This conflicts slightly with comment 4, but it probably just means something was backed out or tweaked between comment 4 & Firefox 34's release.

This worked in yesterday's nightly, though (before bug 1068603's patch made it to trunk), so I don't think bug 1068603 is what fixed it.  --> Removing dependency & adjusting resolution to WFM.

Comment 11

[Daniel Holbert [:dholbert]]

(Good news: I just tested Firefox 35 beta, and this does seem to be fixed there.)