Overhaul name checks

[m4rc1e]

This PR will tidy up our existing name table checks. It also fixes the typographic subfamily name check for VFs with multiple axes.

I've had to move away from using the filenames to determine the family name and subfamily name. Instead, I've used the name table itself. This means I will need to implement a check to ensure that the filenames are related to the name table.

#3191

Still wip, needs much more work.

[m4rc1e]

@felipesanches before you crucify me, I'll use enums and error codes :-)

[chrissimpkins]

IIUC we ignore all name records defined outside of 3, 1, 1033 correct?

Do non-1033 langID have any role beyond locale-specific menu / example text display strings?

[m4rc1e]

@felipesanches Just an fyi. I'm dog fooding this whilst working on an NDA project so my progress is happening slower than expected. I plan on getting this finished in the next fortnight or so. Due to changing the source of truth, we will need to rigorously test this pr.

[felipesanches]

Thanks for putting some more effort on this, @m4rc1e :-)

[m4rc1e]

Thanks and apologies for the delay on this. We should maybe have a hangout once I think it's ready since I'm making a tonne of changes.

[felipesanches]

@m4rc1e, please let me know when this is ready for a code-review. Then if I get confused about some aspects of it during review, we can possibly have a video call for clarification. Cheers!

[felipesanches]

In general, though, I prefer to have the clarification in text comments here so that we keep a public record of the rationales behind all our project decisions.

[felipesanches]

I think it should be __all__ = ["GFNameData"] here.

[m4rc1e]

@felipesanches SGTM.

I took a step back last night and thought it may be more user friendly if we consolidate all the name checks together. Currently, every name record is an individual check which produces massive reports. Imo, it is far more elegant to produce tables which show all the records together. This approach makes the reports much easier to understand since users can see all the info on one page. Since we also use Rich, here's a mock up of a potential friendlier future.

@RosaWagner @vv-monsalve @felipesanches thoughts on this idea?

[RosaWagner]

That is beautiful, I love it !!!!

• style bits could be more explanatory like: is bold, is regular, is italic. use_typo_metric:true, embedding:installable.
• We could have 21 and 22 so it can be useful for other project than GF stuff
• It could be presented the same for copyright and designer info
• actually for all font table related stuff because it is awesome

[felipesanches]

That's pretty good, @m4rc1e !
My original intention when splitting checks into individual fields was to make it easier for the users to grasp because I thought there were too many criteria for the name table to be presented all at once. Maybe I was mistaken. I'm glad you're experimenting with a different approach and it seems to be wise to present it in tabular form. Thanks!

[felipesanches]

Here's a small improvement suggestion:

Use a dark green color for the not-set entries that are good. And say "Not set." in both current and expected columns.

[vv-monsalve]

More structured information, lovely!

So happy not seeing the hexadecimal for the bits enabled in the style bits details, and agree on the explanations could be informative.

Name ID 4 would be relevant and perhaps including ID 25 (while it is needed for Adobe issues).

[vv-monsalve]

Could be this a good opportunity to review the status of this check?

[felipesanches]

It seems that this is now outdated, as we've got a new attempt at #3800