overlap removal warnings and errors, part 3

[lemzwerg]

This is the third of a series of bug reports related to FontForge's overlap removal code. It gets used in LilyPond using FontForge's batchmode to produce the 'Emmentaler' fonts for music notation.

[Based on sources from 2020-02-22 18:07 UTC-ML-TtfDb-D-GDK3.
Based on source from git with hash: af998cc
PythonUI_Init()
copyUIMethodsToBaseTable()
fontforge 20190801
build date: 2020-02-22 18:07 UTC]

Attached is a small input PFB file (arrowheads.open.01.pfb) together with a small script (arrowheads.open.01.txt). Executing

fontforge -script arrowheads.open.01.txt arrowheads.open.01.pfb

produces the following messages.

Internal Error (overlap) in arrowheads.open.01: Winding number did not return to 0 when y=21.6069
Internal Error (overlap) in arrowheads.open.01: couldn't find a needed exit from an intersection
Internal Error (overlap) in arrowheads.open.01: Humph. This monotonic leads nowhere (-0,-21.6113)->(-212.154,-117.651).
Internal Error (overlap) in arrowheads.open.01: couldn't find a needed exit from an intersection

arrowheads.open.01.zip
arrowheads.open.01.txt

This time we have a real error, as the images below show.

Note finally that FontForge version

Executable based on sources from 13:48 GMT 22-Feb-2011-ML-TtfDb-D.
Library based on sources from 13:48 GMT 22-Feb-2011.

handles the glyph without errors (and without warning messages), producing the expected results. In other words, this is a regression.

[skef]

A bit of commentary on this:

This problem reproduces fine in the GUI. I was anticipating that it would be related to x=0 and/or y=0 given the points with those coordinates but it reproduces after a Move transform. The line segment on the right was presumably added by Generate auto-closing the contours; when just running Remove Overlap that spline is missing.

The distortion in the lower shape is due to the co-location of the control point. This is tied to the fact that it's the first point in the lower contour -- if you change the first point to the following one (contour-wise) the symptom moves with it. However, if you change it to the next one after that the output geometry changes significantly.

Finally, rotating away in 90 degree increments eliminates the problem (until you rotate back again). So even a horizontal mirror is handled correctly.

[lemzwerg]

[Version: 20201107
Based on sources from 2021-11-07 08:31 UTC-ML-TtfDb-D-GDK3.]

Still the same error(s).