Tiny serif-like overshoot in glyph id 5171

[mva]

iosevka-term-ss11-medium.ttf from ttf-unhinted-iosevka-term-ss11-19.0.1.zip:

glyph-id 5171 / not a code point? -- "19."

The horizontal line in the "9" on the right overshoots the curve coming from below by a tiny amount. At first I thought this looks similar to the Hryvnia sign earlier, two segments trying but failing to meet in a single point. Unter magnification the lines' meet looks more complicated, with an additional curve leading into the zero width overshoot.

Btw, that's the last glyph id from my list. It was a very short list to begin with. I'm impressed how clean Iosevka's geometry is.

[be5invis]

Perhaps, one suggestion, is you could improve your code's resiliance to "pathelogical" geometry (TT spec DO allow that). I could do some fixes, but do not assume EVERYONE will do that (especially for recent variable fonts).

[mva]

I thought about that after my options for "easy" repair were exhausted.

To my surprise, almost trivial splitting of loops rooted in "on curve" points got me all the glyphs from some sample fonts I am using (Hack, B621, Noto, Liberation2, even good old Times New Roman & Arial).

My options for handling the pathological geometry you mention range from meh (catch exceptions and redirect to .notdef), to slightly less meh (detect non-simple polygons and redirect to .notdef), to larger effort (split arbitrary polygons into simpler ones). I already hit my bookshelf on this, and both effort and computational cost of the last option seem be be close to the triangulation itself once arbitrary intersections between line segments come into play. And I have no idea at all how to deal with contours that have no clear winding order.

Given that the simple approach seems to work surprisingly well, my personal tradeoff is to let it rest for now.

I appreciate the work you put into this and I wouldn't mind at all if you had closed these reports as "won't fix". Thank you very much!