Elliptical arcs are not correctly rendered

Please add information about OS/platform and Inkscape version (see Inkscape menu 'Help > About Inkscape') to the bug description.

Sorry, I did mean to give that info. You can also tell that I went off to do more testing part-way through typing the report and lost my train of thought.

The problem is seen with 0.91 on Windows (Win7 64) and 0.91 on MacOSX. (Though for completeness those are both running on exactly the same CPU in this case).

I should also point out that the problem is that the ellipse is highly non-symmetrical top to bottom. I believe it is basically wider than it should be.

The SVG file inverts Y to suit my application, but the issue was there before I did that. The inversion was actually part of me trying to find out where my ellipse creation code was going wrong.

It looks like it works fine using Inkscape truck from the PPA on LinuxMint 17.1
Here is a screenshot: http://pbrd.co/1EoDK59

inkscape-trunk 1:0.91.0+devel+13916+58~ubuntu14.04.1

- reproduced on Windows 7, Inkscape 0.91 r13725 (Jan 30 2015). If you select the node tool (F2) and hover the mouse over the ellipse you will see a red ellipse that will temporarily appear inside the original object. This red ellipse appears to be the correct rendering. The reason for the distortion is that an attempt is being made to render the entire arc, which is probably about 270 degrees or so, with a single Bezier curve, which is not possible. A single Bezier curve can only represent an arc of about 90 degrees or so with any degree of accuracy.

- not reproduced in Inkscape trunk rev 13919. In trunk, the original permanent object is rendered identically to the temporary red ellipse obtained by hovering with the node tool.

This revision changed experimental to use Cairo to render elliptical arcs:
https://bazaar.launchpad.net/~inkscape.dev/inkscape/experimental/revision/13462
Experimental was later merged back into trunk, and this at least explains why trunk renders this file correctly.

However, 0.91 still uses pathv_to_linear_and_cubic_beziers to render curves.
pathv_to_linear_and_cubic_beziers (src/helper/geom.cpp) attempts to estimate this elliptical arc using cubic Bézier curves, and gets it very, horribly wrong for this specific case. I've determined the problem to stem from within 2geom, and I unfortunately don't know enough of the math going on to really be able to tell where it is going wrong at this point.

I do know that the tailError (3 truncated terms) for the SBasis representing this SVGEllipticalArc is not an accurate to the real error that this conversion would incur.
https://bazaar.launchpad.net/~lib2geom-hackers/lib2geom/trunk/view/head:/src/2geom/sbasis.cpp#L45

Is it likely that the change to use Cairo will be added to 0.91 prior to release?

Yes, I believe that revision is safe to backport.

> Yes, I believe that revision is safe to backport.

From a user's perspective though, that change appears to further "disconnect" the information as rendered on canvas from the path geometry the node tool is aware of (see path outline in the node tool (not the one on hover, the other one which shows depending on the tool option) in trunk, which does not match the actually rendered stroked path). Any node-editing of the path will cause it to immediately revert to the outline as rendered in 0.91, even with that change in.