Intersections sometimes not found between closed path and ray from centroid

[n8willis]

I was attempting to find stress/contrast angles of "o" glyphs using this library and ran into a problem I can't pin down, wherein a ray shot from the center of the o outward sometimes fails to return any intersections with the contour.

The function in question is here:
https://gist.github.com/n8willis/2d6d9c20eccdabc6980d9eb74676858b

I'm not attempting to do anything clever; it is just brute-forcedly iterating around in half-degree steps (measuring the distance from the inner-contour to outer-contour). And the loop works for lots of steps, but on every test font I try it with, it dies at some point reporting that the list of intersections for some ray is empty (specifically:)

i_inner = intersections_inner[0].point
IndexError: list index out of range

That happens at different places on different test-font "o"s; 77.5° in FiraCode Bold; 89.5° in League Spartan, etc. There doesn't seem to be anything topologically similar (e.g., it does not happen when the loop hits a segment endpoint exactly or anything like that) and I don't believe that the glyphs from these test fonts are in any way pathological.

Kind of drawing a blank, and so wonder if I'm overlooking something about the intersections or asSegments() code is intended to function.

[simoncozens]

I think this is fixed; please upgrade to 0.2.0 and reopen if not.

[n8willis]

Well ... the updated release seems to be working all right for #17, but unfortunately it's still returning no intersections in this fire-from-the-center case.

Example, also from Minion Bold Italic:

contour: [B<<190.0,-12.0>-<252.0,-12.0>-<318.0,15.0>-<362.0,53.0>>, B<<362.0,53.0>-<435.0,114.0>-<468.0,207.0>-<468.0,294.0>>, B<<468.0,294.0>-<468.0,390.0>-<418.0,454.0>-<320.0,454.0>>, B<<320.0,454.0>-<277.0,454.0>-<230.0,439.0>-<189.0,417.0>>, B<<189.0,417.0>-<113.0,377.0>-<40.0,283.0>-<40.0,153.0>>, B<<40.0,153.0>-<40.0,76.0>-<71.0,-12.0>-<190.0,-12.0>>]

ray: L<<254.5,221.5>--<254.5000000000001,887.6681469418963>>

On the plus side, it does seem to be failing on nearly-vertical rays, which sounds intuitively simpler. On the down side, it is failing for all fonts.

[n8willis]

Looks like the issue itself can only be re-opened by you, though.

[simoncozens]

The near-verticality was the problem; to find the t-of-intersection on the line was extending the line upwards and upwards until the X coordinate matched. Wrong way. Try 0.2.1.

[n8willis]

This does appear to fix things for the general case, but it's still failing for me when the (expected) intersection is the starting- or ending-point of the Bezier curve. Which wasn't the case for Minion Bold Italic, but is a common occurrence in many "o" glyphs because of extrema. E.g., a vertical ray from the centroid of a perfect circle.

[n8willis]

Sorry; forgot — example, from Baskerville:

path: [B<<76.0,411.0>-<76.0,599.0>-<202.0,725.5>>, B<<202.0,725.5>-<328.0,852.0>-<512.0,852.0>>, B<<512.0,852.0>-<697.0,852.0>-<823.0,725.0>>, B<<823.0,725.0>-<949.0,598.0>-<949.0,411.0>>, B<<949.0,411.0>-<949.0,204.0>-<821.0,85.5>>, B<<821.0,85.5>-<693.0,-33.0>-<512.0,-33.0>>, B<<512.0,-33.0>-<331.0,-33.0>-<203.5,87.5>>, B<<203.5,87.5>-<76.0,208.0>-<76.0,411.0>>]

ray: L<<512.0,409.5>--<512.0000000000002,1698.9669441284643>>

[n8willis]

Just noticed there has been another version bump and some references to this issue in the changelog (86a2beb); it it worth me running my pathological-font cases through on 0.3.x?