Page MenuHomePhabricator

SVG server-side rendering renders some arrowheads backwards.
Closed, DuplicatePublic

Description

Server-side rendering of SVG images is rendering some arrowheads backwards. These are arrowheads at the "start" end of a line.

Compare the arrowheads in the server-side rendered version:

https://upload.wikimedia.org/wikipedia/commons/thumb/f/fe/Adservingsimple.svg/640px-Adservingsimple.svg.png

with the SVG version rendered in Firefox, which is correct:

https://upload.wikimedia.org/wikipedia/commons/f/fe/Adservingsimple.svg

Event Timeline

Nagle created this task.Oct 27 2015, 8:40 PM
Nagle raised the priority of this task from to Needs Triage.
Nagle updated the task description. (Show Details)
Nagle added a subscriber: Nagle.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 27 2015, 8:40 PM
Krenair added a subscriber: Krenair.
Restricted Application added a subscriber: Matanya. · View Herald TranscriptOct 27 2015, 10:21 PM

Eh… it's actually Firefox being the odd-one-out. I tried two other browers and got the same result as the server-side rsvg render.

Firefox:
Blink: (the Chrome browser and friends)
Presto: (old Opera 12)
rsvg


Here's the original .svg file as seen in Inkscape, which created it.

So who's backwards?

Nagle added a comment.EditedOct 27 2015, 11:11 PM


Here it is in LibreOffice 4.2.8.2 Draw with all the arrows at the upper left. That's just broken, but LibreOffice is probably translating it to its internal drawing representation.


LibreOffice Writer, which just has to render it, gets it right.

All this is on Linux; haven't tried a Windows machine yet.

Nagle added a comment.Oct 28 2015, 4:46 AM

This turns out to be a known bug in Google Chrome. See https://code.google.com/p/chromium/issues/detail?id=450368
Firefox, Inkscape, and LibreOffice Writer get it right.

That Chrome bug report blames the user for constructing .SVG files where the end segment is a spline and there's an extra control point at the end. But that may not be the case here. I looked at this file in Inkscape and as text, and I'm not seeing a duplicate point. I tried changing the endpoint of the line to a corner, instead of a smooth curve, and it didn't help. See

https://commons.wikimedia.org/wiki/File:Adservingsimple02.svg

This seems to be associated with putting an arrow at the starting end of the line.

Nagle added a comment.EditedOct 28 2015, 6:30 AM

More info: This problem occurs when one Bezier handle at the end of a line has zero length. This is unusual, but should work. A path like this:

d="m 209.57067,821.56629 c 0,0 -14.05776,36.08917 -29.21747,46.19654 -22.72914,15.15412 -80.782534,13.80346 -80.782534,13.80346"

is a problem. (That means: move to first coordinates, then curve with two Bezier points of the form x1, y1, x2, y2, x ,y, where x,y is the destination in relative coordinates and x1, y1, x1, y2 are the coordinates of the Bezier control points.) At the ends of the curve, the ending handles have zero length. Note the "c 0,0", and that the last two pairs of numbers are the same. The (0,0) value seems to confuse some renderers. It's legitimate to have a degenerate handle at the end of the line; curvature after the end of the line is not meaningful.

If I use Inkscape to force non-degenerate Bezier handles at the ends, it renders properly on Wikimedia. See

https://commons.wikimedia.org/wiki/File:Adservingsimple06.svg

There are a lot of related bug reports:

Reported as bug in Firefox in 2015, and fixed: https://bugzilla.mozilla.org/show_bug.cgi?id=1129854

Reported as bug in Inkscape in 2006, blamed on user and closed as "out of date" in 2009: https://bugs.launchpad.net/inkscape/+bug/167449

Discussion of ambiguity in SVG spec: http://paullebeau.com/svg2/markers/

Discussion on StackOverflow: http://stackoverflow.com/questions/28298441/arrows-in-svg-arent-rotated-when-rendered-by-browsers

I recommend seeing how Firefox fixed it and fixing it that way. The typical user trying to add a drawing to Wikipedia should not have to deal with an issue at this level. Also, there are probably SVG drawings already on Wikipedia with this problem, and no one is going to fix them. Thanks.

Aklapper set Security to None.

Thanks for your investigation. Wondering if this is librsvg territory...

matmarex added a comment.EditedOct 28 2015, 12:57 PM

Yes, definitely. Thanks for investigating. Upstream bug https://bugzilla.gnome.org/show_bug.cgi?id=685906 sounds related, but I'm not sure if it's the same issue exactly?

Nagle added a comment.EditedOct 28 2015, 6:09 PM

Correction:

d="m 209.57067,821.56629 c 0,0 -14.05776,36.08917 -29.21747,46.19654 -22.72914,15.15412 -80.782534,13.80346 -80.782534,13.80346"

means a zero-length Bezier handle at each end of the line. That's sort of bogus, but is what you get by default in some draw programs, including Inkscape. The SVG spec is ambiguous about this. The renderers which get it wrong seem to get it right for the line end, but wrong for the the line start. Thanks.

The way these curves get created is by adding a point in the middle of a straight line in Inkscape, then making it a curved control point. This converts a straight line into a Bezier curve with degenerate end handles. Amusingly, if you then delete the midpoint, Inkscape tries to match the existing curvature by giving the endpoints proper handles, which fixes the problem. So that's how to reproduce this problem, and how to work around it.

Menner added a subscriber: Menner.EditedNov 6 2015, 8:32 AM

T97758 sounds identical. If I don't forget it I'll double check this later as it has been fixed upstream.

Ups, it was Bug https://bugzilla.gnome.org/show_bug.cgi?id=476507

Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptNov 6 2015, 8:32 AM