Page MenuHomePhabricator

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

Assigned To
Authored By
Oct 27 2015, 8:40 PM
Referenced Files
F2883360: libreofficewriter.png
Oct 27 2015, 11:16 PM
F2883352: libreofficeimpresstest.png
Oct 27 2015, 11:11 PM
F2883342: inkscaperender.png
Oct 27 2015, 11:06 PM
F2883299: pasted_file
Oct 27 2015, 10:47 PM
F2883295: pasted_file
Oct 27 2015, 10:47 PM
F2883301: Adservingsimple.svg.png
Oct 27 2015, 10:47 PM
F2883297: pasted_file
Oct 27 2015, 10:47 PM


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:

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

Event Timeline

Nagle raised the priority of this task from to Needs Triage.
Nagle updated the task description. (Show Details)
Nagle added a subscriber: Nagle.

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.

pasted_file (327×498 px, 32 KB)
Blink: (the Chrome browser and friends)
pasted_file (328×503 px, 31 KB)
Presto: (old Opera 12)
pasted_file (328×494 px, 31 KB)
Adservingsimple.svg.png (325×493 px, 32 KB)

inkscaperender.png (243×362 px, 25 KB)

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

So who's backwards?

libreofficeimpresstest.png (461×688 px, 32 KB)

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

libreofficewriter.png (502×715 px, 44 KB)

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

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

This turns out to be a known bug in Google Chrome. See
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

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

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

There are a lot of related bug reports:

Reported as bug in Firefox in 2015, and fixed:

Reported as bug in Inkscape in 2006, blamed on user and closed as "out of date" in 2009:

Discussion of ambiguity in SVG spec:

Discussion on StackOverflow:

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.

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

Yes, definitely. Thanks for investigating. Upstream bug sounds related, but I'm not sure if it's the same issue exactly?


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.

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