#2601 is an example of a more pervasive problem: FontForge doesn't systematically address the problem of a missing cubic spline control point. There are many cases where FF will let you just eliminate one CP and then produce poor output downstream.
A cubic spline with two missing (or, equivalently, on-curve-point-colocated) control points is a line, and is fine. It should be output in point form without both points. A cubic spline with one missing control point is mostly a problem -- ideally there would be none of these.
One can of course just check to see if one is outputting a cubic spline and output a co-located control point, and just editing our various "output" routines would be one approach. However, these splines have undefined slopes at the co-located end, which could screw up some calculations in external tools. It would be better, either always or optionally, to output a control point 1) very slightly away from the on-curve point at 2) the slope calculated at a small t-jump away (small such as 1e-10). That would retain the shape while creating a fully defined spline.
However, there are many contexts within FontForge where one would want that correction. So one could imagine doing this instead on setting nonextcp/noprevcp and every subsequent change to the on-curve points or the remaining control point. The place for that is probably in SplineRefigure(); I suppose the question with that is whether and when folks consider it kosher to modify SplinePoint values via that function. Given that SplineRefigure (often through SplineMake) is supposed to be called on every geometry change it would be a tidy place to implement the change.
I suppose the problem with "always" instead of "optionally" doing that is that some people will want rounded point values and therefore won't be happy with the "tiny-slope" fix. But we can check nonextcp and noprevcp on behalf of those folks and just output the colocated point, given some Pref.
#2601 is an example of a more pervasive problem: FontForge doesn't systematically address the problem of a missing cubic spline control point. There are many cases where FF will let you just eliminate one CP and then produce poor output downstream.
A cubic spline with two missing (or, equivalently, on-curve-point-colocated) control points is a line, and is fine. It should be output in point form without both points. A cubic spline with one missing control point is mostly a problem -- ideally there would be none of these.
One can of course just check to see if one is outputting a cubic spline and output a co-located control point, and just editing our various "output" routines would be one approach. However, these splines have undefined slopes at the co-located end, which could screw up some calculations in external tools. It would be better, either always or optionally, to output a control point 1) very slightly away from the on-curve point at 2) the slope calculated at a small t-jump away (small such as 1e-10). That would retain the shape while creating a fully defined spline.
However, there are many contexts within FontForge where one would want that correction. So one could imagine doing this instead on setting nonextcp/noprevcp and every subsequent change to the on-curve points or the remaining control point. The place for that is probably in SplineRefigure(); I suppose the question with that is whether and when folks consider it kosher to modify SplinePoint values via that function. Given that SplineRefigure (often through SplineMake) is supposed to be called on every geometry change it would be a tidy place to implement the change.
I suppose the problem with "always" instead of "optionally" doing that is that some people will want rounded point values and therefore won't be happy with the "tiny-slope" fix. But we can check nonextcp and noprevcp on behalf of those folks and just output the colocated point, given some Pref.