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

So who's backwards?

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

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.

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.

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

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?

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.

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