Oh, I see, this isn't Remove Overlap. Yes, I've also noticed this! I might see if I can understand what you're doing differently. I agree it'd be good to get this into FontForge :)

Yes, RemoveOverlap has nothing to do with it. Here is an animated GIF for better illustration (left: own algorithm, right: FF algorithm):

@yg8ijvjvjv No, for quadratic curves there is only one possibility leaving the start direction and the end direction intact. And this possibility is already used by FontForge.

Most font designers draw with cubic curves and quadratic is an afterthought. If used at all, autogenerated. I wouldn't expect quadratic drawing tools to improve any time soon.

Patches welcome.

At this point FontForge mostly respects or fails to respect any given font developer by continuing to exist, and that's it. The "systematic" changes tend to be lower-hanging bug fixes; otherwise larger PRs are driven by individual contributors based on their own interests and/or needs. There's no team of developers dedicated to respecting the needs of some groups and thus disrespecting those of others.

tl;dr: what @ctrlcctrlv said.

Well, I have already considered writing a patch by myself. But this will need some time (maybe forever). The function I want to change is:

Spline *ApproximateSplineFromPointsSlopes(SplinePoint *from, SplinePoint *to,
	FitPoint *mid, int cnt, int order2)

which lives in splinefit.c. The struct SplinePoint is defined in splinefont.h and FitPoint in splinefit.h. mid seems to be an array of points with length cnt. The variable order2 seems to be actually a boolean which is true iff the spline is quadratic.
(Just in case you tried to figure out as well...)

You are correct about order2. What George was trying to say is that the polynomial is “of order two”, so a cubic Bézier would be “of order three”.

Also, in FontForge's code, 2 and 3 often have this meaning. See, for example, SplineMake2 (make quadratic spline) vs. SplineMake3. It's a common George-ism.

Bonus: For extra confusion, although George often sticks to order2 for booleans, he uses CID_IsOrder3 once in the UI. 🤭

Meanwhile, I have modified the function ApproximateSplineFromPointsSlopes and removed the now obsolete functions in splinefit.c. The algorithm works as described in the first post of this issue. However, I do not use 9 points on the original spline but the number of points that are given by other function calls (which seem normally just to be the number of on-curve points). So in order to get a better approximation it could be handy to add some points more before merging them... I am not sure, if I want to improve that further because it may be harder to predict how it affects other functions.
Additionally, there seemed to be a duplicate line in splinefit.h which I have removed.

I have tested it today with the newest fontforge sources from github and I did not encounter any problems with the function itself nor related functions (like simplify or ApproximateSplineFromPoints or quadratic splines). Compilations were done with make and ninja as well on a amd64 linux OS.
By the way: I was a bit surprised how fast it is in C in comparison to the Python plugin (about 10 times faster).

Have fun:
splinefit.zip

ApproximateSplineFromPointsSlopes is used by the expand stroke code via ApproximateSplineSetFromGen, so that's one subsystem that would need extensive testing if the former is significantly changed. (An improvement in the per-spline fitting algorithm would reduce the number of offset points, generally speaking.)

If it made sense to tune the number of points generated I could look at that. I think that value is currently hard-coded to 10.

I think 10 is only hard-coded with with expand stroke (not merge). I have forgotten about expand stroke for testing and tested it now: It feels significantly slower with my algorithm than before... I suppose, I could make ApproximateSplineFromPointsSlopes 4 times faster and even 10 times faster for half of the cases. Let me figure out this first and than I come back to your offer tuning the number of generated points. It could be that 10 points are important to figure out the self-intersecting points of the stroked path...
@skef How is the self-intersecting point of the stroked path at a high curvature point of the stroking path determined? With removeOverlap?

... You could also keep two versions of the function around and use them in the appropriate places. 🤷‍♂️

If there are any self-intersecting or self-cusped shapes passed to the fitting functions they would be strange corner-cases I haven't run into. The code doesn't trace the regions between offset cusps -- it detects them and cuts off the traced shape.

It's possible that if individual "source splines" are cusped or self-intersecting you could get analogous features in the offset contours but it's less likely you'd "see" them in a single fit given that they'll be segmented by the angles determined by the nib control points. Maybe you would. I'm not sure these are cases we need to handle perfectly or even well -- including such splines in your input geometries is sort of "asking for it".

On 10 fit points: I picked this somewhat arbitrarily as a "sufficient" number. The system I was replacing was much, much slower so I didn't stress too much about tuning it for maximum performance.

ApproximateSplineSetFromGen self-evidently enforces its own fit tolerance. One risk of lowering the number of fit points is failing to detect areas that don't match the offset geometry because they aren't represented in the sample. In theory that could be addressed by splitting the sample used to fit and the sample used to check (e.g. passing four points to ApproximateSplineFromPointsSlopes but then checking all ten points against its output).

I have made the variation rougher i.e. slightly less exact but 4 times faster (both handles 2 times rougher makes it 2*2=4 times faster). And I have calculated the lengths of the handles where they would intersect and which makes it again about 2 times faster for generic cases in font design (i.e. the handles are on the same side of the chord and the angles of the handles to the chord are smaller than 90° each):
splinefit20210107.zip
I have tested it a bit and on my computer the speed for stroking a path is quite okay although I think it is still slower than the original version.
Maybe @ctrlcctrlv is right and I should separate merge and simplify from stroking a path but at the moment I will not look into that because I do not have the time to do so and my current splinefit patch already meets my needs.

Here an example how simplify works with my patch:

The same example did not simplify anything before and when the corresponding splines are merge one got without patch:

I was wrong writing that I will not look into making a separate function soon. Well, here is a new version of my patch:
splinefit20210108.zip
I have restored the original functions in splinefit.c and named my additional function ApproximateSplineFromPointsSlopesAccurate(). This additional function is mentioned in splinefit.h such that splineuitl2.c can find the function. In splineuitl2.c I have only changed one line in the function SplinesRemoveBetween() from ApproximateSplineFromPointsSlopes() to ApproximateSplineFromPointsSlopesAccurate().
This patch is probably a good compromise: "Merge" is rarely never called in a batch process and I cannot feel any speed issues when I use it (though I know it is about 10 times slower than the original function). The patch does not affect "Simplify" nor "Expand Stroke" (which are called in a batch process and need to be fast).
The only thing that is not elegant is that I have just copied the first part (cases like order2) from the original function. Maybe I should check all these cases first and call the original function then if the cases are met?

By the way, the following was a bad idea for parts that involved inflection points and I ditched it: "And I have calculated the lengths of the handles where they would intersect and which makes it again about 2 times faster for generic cases in font design."

@yg8ijvjvjv

How would the TrueType simplify work then?

I have already pointed out that "Merge" has only one solution for quadratic splines and that Fontforge is already using this solution.

That's great, you should PR it. If you PR it artifacts will be built so it can get more widely tested as well.

In re Simplify command, if I were you I would add a configuration option for "more aggressive, but slower, simplification". But this isn't needed for merging IMO. I just think it'd make a good option. Others might disagree.

If this gets PR-ed I'll probably add an option to use it instead of the current function in Expand Stroke. (This is easy enough because Expand Stroke already offers numerous options so it's at most a UI headache.)

Simplify is trickier because it doesn't currently have parameters but @ctrlcctrlv's suggestion of a global config parameter seems like the way to go. We could probably add a one-off control at the python level as well.

I agree that none of this would be needed to merge the PR.