On 6-8-2014 20:16, Liam White wrote:
On Wed, Aug 6, 2014 at 1:56 PM, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
 I think this should either be changed to
strict equality
I agree with this. While rounding errors might cause strange behavior in some cases, I'm fairly certain the vast majority of these "impossible-to-draw" arcs are going to be generated by our internal library livarot incorrectly writing arcs. Which means that the endpoints are going to be exactly the same, not simply within rounding error.

or there should be a way to set this threshold (in
Inkscape, it should be dependent on the numeric precision of XML
output).
Hmm. Well, that is actually a better solution since the user would then be able to control how far the precision can go to retain the arc, instead of a hardcoded value.

Unfortunately, I cannot reproduce the original crash on my system, so I cannot test corner cases. Using strict equality looks like a very tricky solution to me, prone to bug on different systems/compilers/etc. If I understand the bug report correctly, the crash does not happen on parsing the path, but rather on some later operation on it, suggesting that it depends on the internal accuracy of some 2geom processing. If that's the case, then the threshold should depend on that (I feel), and not on XML representation precision.

I agree that the hardcoded threshold is arbitrary, but I think it is better than guessing what g_ascii_strtod is doing with e.g. "0" and "-0" on different systems. The 1e-5 is quite large though, and should be reduced.
If we make arc parsing dependent on an XML representation precision parameter, what is that precision?
Currently:
Our XML precision thing is a little strange now too where with precision setting 4:
M 0,0 A 20,30 45 1 0 0,1e-5  is allowed and draws an ellipse
M 0,1 A 20,30 45 1 0 0,1.00001  is not, and will not draw the ellipse

I suggest we move the threshold to something like 1e-8, which then works out well for default Inkscape prefs, and solves the potential problems of strict float equality.

Another consideration is whether we should move the equals check from Parser to PathSink implementations.

-Johan