mgbella
commented
2 months ago @arrowtype Thanks for creating this; I've meant to do it for a long time. It's just been part of my own workflow to do an install test and manually check it. Until it's fixed by MS or until someone can pinpoint the exact culprit, the WARN is exactly what I would hope for as well—at least to flag it so it could be checked manually. AFAIK, the Σ√≠bug is purely cosmetic.
Cheers.
What needs to be checked?
The Windows Font Settings panel displays fonts with icons to preview their general look. Unfortunately, many fonts preview as "Σ√≠" rather than "Abg," which isn’t very helpful.
This seems like a Windows bug, as it occurs even when fonts are straightforwardly meant for Latin text, and just happen to include OS/2 information that they include glyphs in the Mathematical Operators Unicode Block. This bit seems to be checked by FontMake builds for almost all fonts, if they contain glyphs in this block, such as the
/(the basic forward slash).FontMake seems to be working properly by doing this, but it seems to be fairly common practice for foundries to uncheck the Mathematical Operators bit of the Unicode Page Ranges, to workaround this Windows bug.
Detailed description of the problem
This seems to be a long-running issue. I’m seeing it on Windows 11, 22H2. However, the bug (and the workaround) is documented at least as early as 2015 on TypeDrawers. Recent discussion at https://typo.social/@arrowtype/112272933176102051 shows that it is a fairly common problem, and that a common workaround is to removed the math operators bit.
It is possible there are more in-depth factors at play, as the bug doesn’t occur on every font that includes the math operators bit. For example, when fonts do have the "math operators" bit set but don’t include specific PANOSE information, this usually doesn’t seem to occur (e.g. in Shantell Sans). You’d think this might be due to the presence of a meta table, but that doesn’t always seem to be the case (again, in Shantell Sans).
However, it does seem like removing that bit is a reliable way to avoid the bug, so unless there is a better way, or unless/until we can somehow convince MS to fix the bug, it seems like something worth making a FontBakery check to flag.
Resources and steps needed to reproduce the problem
A frustrating part of this problem is that it seems easy enough to avoid by removing the math operators bit, but there are also examples of fonts that do include this, and don’t exhibit the problem. For example, Shantell Sans, Recursive, and Ubuntu all preview as "Abg," despite having this bit set. But, clearly this is a well-known, long running problem, so it would be good to alert font makers if there is known workaround. I’ve had it happen to multiple recent fonts created with FontMake and GF Builder workflows.
Suggested profile
Suggest which profile the check should be added to. The most common are:
Universal (Probably?)
Suggested result
Which log result level should the check have:
⚠️ WARN (A potential issues that may need to be addressed)
Severity assessment
2 or 3. It makes the font appear somewhat broken or janky on Windows, but it doesn’t seem to have any further impact.