Measure tool: flakiness with constrained measuring

[su_v]

Follow-up report to
Bug #796451 “Measure tools should support rotation constraint”
Bug #796450 “Measure tools should support snapping”

As commented in the earlier reports, the measure tool detects different intersections while dragging the measure path horizontally with 'Ctrl' pressed (or when snapping e.g. to the grid):

«measuring at 0° (…) still has randomly incorrect intersections/gaps measured (…), depending on current cursor position while dragging the mouse slightly with 'Ctrl' still pressed. Results can vary depending on measuring across sub-paths of one object or across segments of different objects.»

Tested with Inkscape 0.48+devel r11533 on OS X 10.7.4.

[su_v (suv-lp)]

sample screenshot (r11533)

[ScislaC (scislac)]

Reproduced w/ 11533 on Ubuntu Quantal

[su_v (suv-lp)]

Another example exposing odd non-existent intersections when measuring length and angle of straight line path segments.

[su_v (suv-lp)]

Screenshots, all done by measuring length and angle of the two-node
lines, measuring along the path - radially outward - with node snapping
(to the cusp end nodes). There are no inner nodes, or other intersecting
elements which could explain the results of the measure tool.

[Ryan Lerch (ryanlerch)]

Confirmed on Inkscape 0.48+devel r12500

Attached is a screencast of how i reproduced it

[Diederik van Lierop (mail-diedenrezi)]

This is what I just posted to lib2geom-devel:

Hi everyone,

When looking into this bug in Inkscape's measure tool:

https://bugs.launchpad.net/inkscape/+bug/1022733

I found out that intersecting two parallel line segments typically produces 50 - 100 crossings. This should either be zero or infinite (or maybe one if one line segment is just a point).

The original code checked for a cross product being exactly zero as a measure for line segments being parallel, but that's obviously a bad idea. I've found the error to be < 1e-13, so I propose checking for a cross product of < 1e-12.

This solves the bug I was trying to squash, but I'm not too familiar with the crossers code. If someone objects to this fix, then just speak up!

Thanks,

Diederik

=== modified file 'src/2geom/path-intersection.cpp'
--- src/2geom/path-intersection.cpp 2014-03-27 01:33:44 +0000
+++ src/2geom/path-intersection.cpp 2014-05-14 18:47:54 +0000
@@ -169,15 +169,21 @@
           Bd = B1 - B0,
            d = B0 - A0;
     det = cross(Ad, Bd);
- if( 1.0 + det == 1.0 )
- return false;
- else
- {
- double detinv = 1.0 / det;
- tA = cross(d, Bd) * detinv;
- tB = cross(d, Ad) * detinv;
- return tA >= 0. && tA <= 1. && tB >= 0. && tB <= 1.;
- }
+ if( fabs(det) < 1e-12 ) {// If the cross product is NEARLY zero,
+ // Then one of the linesegments might have length zero
+ if (!are_near(A0, A1) && !are_near(B0, B1)) {
+ // If that's not the case, then we must have either:
+ // - parallel lines, with no intersections, or
+ // - coincident lines, with an infinite number of intersections
+ // Either is quite useless, so we'll just bail out
+ return false;
+ } // Else, one of the linesegments is zero, and we might still find a single intersection point
+ } // Else we haven't bailed out, and we'll try to calculate the intersections
+ std::cout << "det = cross = " << det << std::endl;
+ double detinv = 1.0 / det;
+ tA = cross(d, Bd) * detinv;
+ tB = cross(d, Ad) * detinv;
+ return tA >= 0. && tA <= 1. && tB >= 0. && tB <= 1.;
 }

[Diederik van Lierop (mail-diedenrezi)]

Fixed as of rev. #13397