I have realized that the quadratic splines are still not handled correctly. Consider the following contour where I want to make the lower left node smooth (image left: before point conversion; image right: after point conversion).

The tactic I am using now is to take the average direction of the handles . However, in some cases there is no intersection of this average direction with the direction of the handles of the next nodes (or the intersection is on the wrong side). This should be fixed before merging.

Just to be clear: This is not a programming issue; I do not know how to handle this situation at all. Suggestions and hints are welcome!

@linusromer I just tried a similar shape in what amounts to the current code and the whole contour changes. There seem to be a lot of cases with quadratic splines where there's no good solution and what FontForge does isn't great. (I certainly wouldn't want my whole contour to change as a result of changing one point type.)

This is a long-winded way of suggesting that the current solution may actually be fine. I suggest playing around with quadratic splines and the current heuristics to see if you convince yourself of something similar.

Oh, I guess it is a problem if the control points aren't coincident ...

I think it would be fine to leave the current algorithm for quadratics. It would also be fine to adjust the tangent angle to be the average (if that's not what already happens) and then to run the current algorithm. So much changes otherwise that the angle seems like a detail.

@skef

It would also be fine to adjust the tangent angle to be the average (if that's not what already happens)

Indeed, this happens already. I think there exists no proper solution for this problem (e.g. Fontlab struggles with my example contour, too). After thinking a bit I came to the conclusion that it would be best to leave the control points at their original position when this very specific problem occurs (the user has to interact anyway).

As far as I have checked, the patch should now be ready for merging.

After commit a0dc9d5 has been pushed, I have tested my patch again and I have discovered and fixed some minor curve updating issues after conversion to tangent and added better behaviour for conversion from hvcurve to curve.
There is a small remaining issue: After conversion to tangent in quadratic splines, FontForge does not make the adjacent line really to a line:

I am not sure but I fear there is no MakeLine() function for splines and some kind of CharChangedUpdate() may be needed instead to fix this behaviour.

@linusromer I can look at the remaining problem but a quick set-of-steps-to-reproduce would be handy for me.

@skef I have made an example font with a contour made of quadratic bezier splines:
quadr.sfd.zip

The left part shows the original state of the contour and the right part shows the spline after two independent changes from me:

• I have made the spline DA to a line with "Make Line" from the menu. The control point is still displayed, which is a visual problem. However, it is also problematic when I want to move point B afterwards: Then the line DA is magically converted back to a curved spline.
• I have converted point C to a hv-smooth point. The displayed splines adjacent to C do not update afterwards (but they should of course).

The "Make Line" problem may be a little above my pay grade, as I'm not sure what the relevant issues are. The problem is that guard in SplineRefigure2 on line 1249 of splineorder2.c is failing because from->nextcpindex check. What's that about? As I understand it it's trying to preserve TTF point numbering.

This may be a simple local/global problem. If you eliminate the control point then you need to renumber all the points. SplineRefigure isn't really the level to try to do that sort of thing. There may also be TTF/quadratic spline font reasons to preserve the numbering. I really don't know much about quadratic spline font production.

This seems like something you may just have run across that isn't directly related to your changes here. Is it something we could file an issue about and leave for another time?

Yes, my example already showed that it has nothing to do with my changes because the two problems were already existant with current Fontforge versions. I just hoped the two problems could be fixed easily and the fix could be packed in this PR. But after your comment I agree that it is wiser to file a separate issue and merge my PR in the current state because it is absolutely independandt.

For the hvcurve problem: Isn't this just that the code between lines 725 and 745 that handles pt_hvcurve doesn't have any calls to SplineRefigure()? (For example, compare with the code below for pt_curve.) This diff seemed to work well for your test case:

diff --git a/fontforge/splinechar.c b/fontforge/splinechar.c
index 40bba8391..3a44fb3cf 100644
--- a/fontforge/splinechar.c
+++ b/fontforge/splinechar.c
@@ -737,11 +737,13 @@ return;
            sp->nextcp = ncp;
            if ( sp->next!=NULL && sp->next->order2 )
                sp->next->to->prevcp = ncp;
+           SplineRefigure(sp->next);
            pcp.x = sp->me.x + unitprev.x*prevlen;
            pcp.y = sp->me.y + unitprev.y*prevlen;
            sp->prevcp = pcp;
            if ( sp->prev!=NULL && sp->prev->order2 )
                sp->prev->from->nextcp = pcp;
+           SplineRefigure(sp->prev);
            makedflt = false;
        }
        if( pointtype==pt_curve ) { 

I just reviewed the code and it looks fine to me. I'll leave it for a few days in case @jtanx or someone else wants to take a look and comment and if not I'll approve it.

@skef Well, yes, this solves the problem. I have added your patch. (Some time ago SplineRefigure() was called anyway at another place but this call was cancelled by a commit in the last year.)
And for the "make line"-problem: In the version 20190801 the "make line" command worked but the numbering problem was solved very improperly (all nodes kept their numbers but the numbers had gaps afterwards like 1,2,4,5). I guess, it's better to leave it in the way it is now to solve the numbering problem properly. With the knowledge I have now I would say that this PR can be merged and no additional issue should be filed.

There were many consistency problems with cubic splines and control points (or lack thereof) before #4685. I wouldn't be surprised to learn that there were related quadratic spline/point numbering problems as well. My guess is that that commit reactivated a consistency check in SplineRefigure2 that wasn't being applied before.

MakeLine should probably work in this case, as its changing the geometry so there's no need to preserve TrueType hinting (which depends on point numbering). The problem is that there isn't a consistent way of addressing point numbering in the code, at least that I can see. What's probably needed is a point numbering "philosophy" implemented with a commit similar in scope to #4685. Before that happens the current convention of leaving the point in SplineRefigure2 seems like the lesser of evils.