New check: Detect colliding accents at small pt sizes

[m4rc1e]

A user just reported an issue where the acute in Eacute collides with the base glyph at certain sizes in the Tenor family.

A possible heuristic to detect colliding accents is to the render the glyph (hints must be enabled), do a DFS/BFS on the pixels and count that there are at least two black shapes. However, there are some exceptions such as Aring etc where the ring could be connected to the A or accents on ligs where one would expect even more shapes. This implementation may also be too slow for massive families though.

[m4rc1e]

This reminds me of the "Recommended contour count" check I implemented many moons back. I doubt we can get it perfect but it will be useful regardless. Don't mind calling it "Recommended shape count". Again it will feature a totally biased hashmap 😿 which we can generate from our popular families.

[m4rc1e]

Instead of using a hash map, a better solution could be to render each glyph twice, one at a large size, the other at a smaller size and check whether the smaller size has less shapes.

[felipesanches]

yes, I agree that's a better approach

[felipesanches]

@m4rc1e, please remember to always provide links to the original issue in cases like this.

Here, the relevant one is https://github.com/google/fonts/issues/4075

[felipesanches]

I'm starting to implement this one now. I fear it may be a time-consuming check though as running the pixel algo at least twice on all glyphs of a given font will likely be a slow task, even with a well optimized implementation.

I considered using Simon's collidoscope module, but that would not detect issues caused by bad hinting, so my current approach is to use Pillow to render tiny bitmaps.

[felipesanches]

I started implementing this, but I am having a hard time making it work, so I will open a PR to share the WIP code