[builder] move the mac names specific to VF to platform 3?

[RosaWagner]

I transmit here the conversion we had in the group chat to keep an archive and have more opinions:

Original question:
Is there a reason why we have nameID 25 + custom names linked to STAT and FVAR (25* to 27*) in platform 1 instead of platform 3 with the rest of the name tables?

Adam said:

As we know, variable "OpenType" fonts have been working in Mac OS since Mac OS 7.5 released in 1994, and if packaged as TTF, since the first version of Mac OS X published in 2001. This is because TrueType-flavored variable fonts are backwards-compatible with TrueType GX Variations. But until Mac OS X 10.13 High Sierra (2017) or 10.14 Mojave (2018), not sure now, the predefined instances in the fvar table only worked if their names were registered in the Mac classic PID 1 EID 0 name table branch.

Even though macOS started preferring the 3.1 name entries for other names, Apple’s TT GX code was dormant for years so nobody updated that part, until, I think Mojave. There is still some portion of users of Mac OS X Sierra and High Sierra, especially since older Apple hardware is actually surprisingly resilient, and still yields good prices on secondary markets. In some countries, a seriously older Mac with old Mac OS X is still a machine that is much in demand.

So main concern is backward compatibility.

Although, Dave recalled that these OS don't support VF so well.

Also Olli (@moontypespace) told me by email:

Even Apple’s SFCompact.ttf system variable font does not contain Mac name table entries anymore.

cc @vv-monsalve @davelab6 @twardoch @m4rc1e

[ollimeier]

@RosaWagner Thanks for bringing this up. I would like to add to this conversation, that Dave Opstad (http://luc.devroye.org/fonts-43562.html) told me, we should not produce fonts with Mac entries anymore. Dave helped develop the TrueType font format at Apple (for many years) and is one of the authors of Apple's GX.

[felipesanches]

@moontypespace has provided a new FontBakery check related to this discussion at fonttools/fontbakery#3545

If we ever consider this a generic check, then we should consider incorporating it on FontBakery's 'universal' profile, but I'd like to get some feedback from you all before we do so. So, for now. It will stay on the newly created Fontwerk profile.

Feel free to open an issue on the FontBakery issue tracker if any of you feel that this should be in universal.

[Hoolean]

As of the latest Font Bakery release, the above check has been promoted to the Universal profile, and so boilerplate gftools repositories are FAIL'ing.

To confirm, has the decision been made that Mac name records should not be shipped moving forwards? If so, how best to prevent them being added by gftools' STAT and fvar generation moving forwards?

Happy to contribute a PR :)

[ollimeier]

Hi @Hoolean ,
if you use fonttools to create the STAT table, there is an argument macNames=False you can specify, similar to this:
buildStatTable(font_obj, AXES, macNames=False)

https://github.com/fonttools/fonttools/blob/46cb2d078adebb0830d054052c1a489e699583b0/Lib/fontTools/otlLib/builder.py#L2710

[ollimeier]

You can also remove all mac names with: font_obj['name'].removeNames(platformID=1)

[Hoolean]

Thanks Olli! Understood on the fontTools approach, just wanted to start a discussion here about the behaviour 'out of the box' in gftools to avoid the need for those manual steps in several different projects. (although I probably will be submitting a small PR to this repo that changes the arg that is being provided there indeed :-)

[simoncozens]

Out-of-the-box gftools should absolutely produce fonts which pass GF's checks. :-)