Add check for broken accents, like ABeeZee ė

[davelab6]

Observed behaviour

ABeeZee has a problem with ė

(reported at https://github.com/google/fonts/issues/2014)

Expected behaviour

FontBakery should detect this kind of problem, so we know how bad it is across our library.

[davelab6]

@rsheeter pondered how to implement this:

I wonder if this is detectable across our whole collection by running a large set of combining char combinations through shaping and observing if the result is mildly sane. There aren't that many combining marks and the rough landing place is fairly well known for many (all?). For example, a mark chilling alongside is usually going to be a bug.

[felipesanches]

I talked to @m4rc1e earlier today about this issue.

I noticed that ABeeZee-Regular.ttf does not include a glyph for codepoint U+0117 'LATIN SMALL LETTER E WITH DOT ABOVE'

I initially thought that com.google.fonts/check/glyph_coverage would detect this glyph missing. But this check only inspects the font considering conformance to the GF Latin Core glyphset, which is the bare minimum that all fonts in the Google Fonts collection should provide. The E with dot above is only listed in the GF Latin Plus Unique glyphset (https://github.com/googlefonts/gftools/blob/e58fa6f54d662c237f47b39c2feb2017cb53689f/Lib/gftools/encodings/GF%20Glyph%20Sets/GF-latin-plus_unique-glyphs.nam)

I might add more checks for all the GF glyphsets, but making them all WARNs, except for the GF Latin Core which should remain a FAIL-level check.

In the long-run we might want to have something like pyfontaine to check all glyphsets. We used to have something like that in fontbakery some time ago. I am not sure why we gave up on that back then.

[laerm0]

re @rsheeter's comment: Can't @m4rc1e's machine learning tool figure this out?

[felipesanches]

@m4rc1e also suggested using something like this to inspect combining marks in a font: https://docs.python.org/2/library/unicodedata.html

[felipesanches]

The reason why the dot is floating is because the U+0117 glyph is not available, so the renderer ends up rendering the separate components instead.

[rsheeter]

Why would we need ML to figure out that a mark is completely mispositioned? - I buy we might need it to do a full "it's really good" assessment (and that may have value) but we are overcomplicating things to say we need ML for an error this basic.

[felipesanches]

ABeeZee lacks the composite glyph U+0117. So the issue here is not about misplaced marks, but instead about glyph coverage (certain glyphs not being available at all in a font, instead of being malformed).

[felipesanches]

yes, I agree that this does not require machine learning.

[laerm0]

I guess I was thinking that Marc had that thing looking pretty cool last summer and maybe it was ready for some work now.

[drott]

CC behdad@

[davelab6]

@felipesanches @simoncozens I came across this during my internal bug bash; I wonder if it can be prioritized in the upcoming dev cycles using the advances made since 2019 :)

[felipesanches]

It seems to me that the only brokenness in this font causing the issue is the lack of a glyph (for codepoint U+0117 'LATIN SMALL LETTER E WITH DOT ABOVE') . So, it is not so much a direct FontBakery bug, but instead, indirectly, a matter of defining glyphsets for coverage checking, so it is more of an issue for the glyphsets package. Should we migrate this issue to that repo? (https://github.com/googlefonts/glyphsets)

[felipesanches]

In other words, what I mean is that "check for broken accents" should instead be just "check for glyph coverage", which we already have. And which sets to enforce is a debate for the googlefonts/glyphsets package.