As far as the output to other formats goes this was always the case,
just not to as many segments as now.
Right, but that code didn't change, so I assume this is the result of the default
tolerance being made smaller.
The default tolerance didn't change but the code in sp-ellipse.cpp did. A few
revisions ago the ellipses were created by explicitly calculating four Bezier (!) curves
so there was no need for any conversion. Now I changed this to creating elliptical arcs
and let 2geom do the calculation. Have a look at this bug report:
https://bugs.launchpad.net/inkscape/+bug/1235504 .
Try the patch I attached there (e_to_b.patch). This increases the tolerance to an
arbitrary value of 1, so only for quite big ellipses more than four nodes are generated.
Of course this value should be accessible via a settings tab later. Would this be an
acceptable solution then?
Regards,
Markus
-----Ursprüngliche Nachricht-----
Von: system user for webserver-base [mailto:apache@...2855...] Im Auftrag von mathog
Gesendet: Samstag, 19. Oktober 2013 00:19
An: Markus Engel
Cc: 'Inkscape Devel'
Betreff: Re: AW: [Inkscape-devel] Recent change to ellipse to path conversion method?
On 18-Oct-2013 14:58, Markus Engel wrote:
This has to do with the change that ellipses are represented now as
true elliptical arcs. These are converted implicitly to several Bezier
segments.
As far as the output to other formats goes this was always the case, just not to as many
segments as now.
pathv_to_linear_and_cubic_beziers() does this conversion using a
certain "tolerance".
Right, but that code didn't change, so I assume this is the result of the default
tolerance being made smaller.
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.
That sounds good. Can the default value please go back to where it was?
I don't recall hearing a lot of people complaining about a lack of precision in the
representation of ellipses and the tolerance change resulted in unexpected output
differences.
I suppose you also need to make a distinction between what is going on on the drawing
surface and the precision on a forced conversion to another format. Lots of graphics
drivers have precision settings that affect what is seen on the display but which do not
change the underlying data representation. This is super common for
"smoothness"
settings on 3D rendering, for instance. The current change seems to affect both.
"Screen tolerance" and "Conversion tolerance", if you will.
Regards,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech