intentional is the wrong word. This has to do with the change that ellipses
are represented now as true elliptical arcs. These are converted implicitly
to several Bezier segments.
pathv_to_linear_and_cubic_beziers() does this conversion using a certain
"tolerance". Thus, if the elliptical arc and the bezier curve differ too
much, a new node is inserted automatically.
Currently I'm thinking about a solution, as this is not quite user-friendly.
One of my ideas was that we could introduce a new tab in the settings dialog
where you can choose the tolerances for these path conversions yourself.
So the average user could choose a high tolerance and get fewer (at least 4)
nodes, the cad user who needs high precision, could set the tolerance to a
What do you think?
Von: mathog [mailto:mathog@...1176...]
Gesendet: Freitag, 18. Oktober 2013 23:25
An: Inkscape Devel
Betreff: [Inkscape-devel] Recent change to ellipse to path conversion
Earlier today I found one small bug related to images written to WMF files
and posted it in launchpad. But while working on that noticed that there
was also another binary change in the output that didn't correspond to
anything I could see in the images. A careful byte by byte comparison of
EMF and WMF output from the lp988601 and current trunk branches showed that
outside of my code there has been a change, where the paths returned on
ellipse to path conversions are not as they once were. In emf-print.cpp in
the print_simple_shape() routine a print statement was added after the call
pathv_to_linear_and_cubic_beziers() and the loop which adds up nodes, lines,
and curves. For the exact same ellipse (long axis aligned with x, short
with y, axis ratio about 2:1) this is what was found:
nodes lines curves
lp988601 5 0 4
trunk 9 0 8
They start at the same point, but differ from there. Tried it again with
perfect circles and got the same result.
The strange thing is that there is no change at all to the geom.cpp file,
where pathv_to_linear_and_cubic_beziers() is coded.
I also checked to see if anything similar could be seen in the GUI, and it
sort of could be. Select the ellipse, select "stroke to path", then edit
points. The points on the ellipse are in different places in the two
branches, and there are different numbers of points. For lp988602 there is
one point on the end of each axis plus one point in roughly the center of
each quadrant. For trunk there are the same points on the ends of the axis,
plus two points within each quadrant, and these are clustered towards the
"sharp" ends of the ellipse.
Is this change intentional???
Manager, Sequence Analysis Facility, Biology Division, Caltech
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
from the latest Intel processors and coprocessors. See abstracts and
Inkscape-devel mailing list