Use "proper" automatic production names for whitespace characters

[rimas-kudelis]

One of the checks performed by FontBakery is FontBakeryCheck:com.google.fonts/check/whitespace_glyphnames, which checks whether "Font has proper whitespace glyph names?".

When I build the font I'm currently working on without telling fontmake to use production names and without having a public.postscriptNames dict in the lib, this check will complain that Glyph 0x00A0 is called "nonbreakingspace": Change to "uni00A0".

If I build that same font and tell fontmake to use production names, but still don't have the public.postscriptNames dict in the lib, this check then complains that Glyph 0x0020 is called "uni0020": Change to "space" (or something like that).

If I create the public.postscriptNames dict and add only a single entry for space to it, the result is effectively same as not using --use-production-names and not having public.postscriptNames at all: all glyphs retain their design-time names (because my space glyph is already called "space"), and FontBakery again complains about the "nonbreakingspace" glyph.

I'd really like to avoid having to maintain a huge mapping between my glyph names and Postscript names, since it's something that could (and should) be easily derived from the data that is already in the UFO. While I would prefer AGLFN names (#211), I don't mind having "uniXXXX" names either. But, as explained above, FontBakery does mind that.

Could ufo2ft please use glyph names that satisfy FontBakery when usage of production names is requested?

[anthrotype]

That check is bogus, there's no reason to reject glyph names "nonbreakingspace" for the character 0x00A0, or "uni0020" for the space character 0x0020. They comply with AGL and all software that cares about glyph names know how to parse them.
You can raise an issue on fontbakery upstream repository if you like.

I understand you don't want to maintain a long mapping of postscriptNames. As you found out, ufo2ft can either read your mapping from the public.postscriptNames (a complete mapping, not a subset of the names you want to rename), or it can convert all the names to uniXXXX sort. The latter should also be a perfectly valid way to name glyphs according to the AGL specification, which the AGLFN spec is merely a subset, excluding glyphs that were mapped to PUA codes and should therefore be avoided "for new fonts". But that's not the case for those whitespace characters.

If there's a stronger argument for resurrecting #211 I won't reject it this time, only that I don't have the time to work on this as it's very low priority.

I also believe that fontbakery is only issuing warnings, not errors for the above mentioned glyph names. So you should have the option to safely ignore them.

[rimas-kudelis]

I also believe that fontbakery is only issuing warnings, not errors for the above mentioned glyph names. So you should have the option to safely ignore them.

Yes, they are warnings, but it's still unsettling and suggests that something is not quite right.

I'll raise an issue with FontBakery, like you suggested.

Thanks!

[rimas-kudelis]

@anthrotype, I'd say one argument for resurrecting #211 is because it makes errors and warnings produced by font validation tools (or any other error messages wherever) easier to act upon, if your development names are at least somewhat aligned with AGLFN.

When a message says that "something is wrong with uni1234", you end up having to look up what character that is and then look for your corresponding glyph before you can look at the problem itself. If the message presented both the codepoint and the AGLFN glyph name, it could help save some time.

OTOH, if your development names aren't aligned with AGLFN at all, this may be even more confusing, though that's why I suggested above to output the codepoint as well.