Just wanted to note to users that I - more or less - fixed the long existing odd behavior when using the intersection notches when one edge is on the fold or the SA is zero as below.
I spent 1/2 the day Sat trying a whole bunch of different ways to fix the issue, and kept coming up with the same problem with some cases. I’ve come to the conclusion that many of the odd behaviours in the app arize from the use of floating point math which cause things to be close, but not exact. Basically using FP is trying to split pixels, which you cant.
For example… here’s the issue more or less fixed - as long as you select the correct angle type for Point A given the position and zero SA. Selecting different angle type can cause the far upper left cut line point to drift (right) due to FP math by as little as .000000001 and it is no longer on the line along A3 to A… so there is no intersection found to locate the notch on the cutline. Unfortunately the Qt intersects() routine does not use fuzzy math, and that’s why I think odd behaviors happen. I think if Int math is used we wouldn’t be trying to split pixels.
Curves also present issues as you may find tweaking a control point .0001 of an inch will make a notch work. Like I had to do below.
I tried a different method to to project the notch point, but then ran into the issue of then having to do trig to find the correct length in the case like below instead of finding the intersection. The trig just presented more FP issues so I went back to just finding the intersection.
At any rate, like I said - for the most part - the issue is fixed, with the exception you may find the notches on a fold do not appear… mainly if it’s an example of a curve with no SA. - which is in reality not something you do. That is put a fold on a curve.