Treat nameID 2 and 17 as font feature record

[ptoussai]

This is a fix for #272

[quitequinn]

Can we accept this pull request? @devongovett @blikblum

[Pomax]

This wouldn't be correct, though. Name ID 2 and 17 have firmly established meaning, being the font subfamily records (see https://learn.microsoft.com/en-us/typography/opentype/spec/name#name-ids). Playing a guessing game using Name IDs over 25 is fair game, but 1 through 25 are off limits.

[quitequinn]

Currently, fontKit is giving inconsistent results for fonts that work as intended. The fontkit.openSync('font.ttf'). namedVariations have an expected format, a format that I believe fontKit decided on, and fonts that use Name ID 2 to select the named value are causing fontKit to break that convention. I also don't think this is a situation where we can blame the font developer — they aren't the intended audience of fontKit.

I would argue that regardless of whether Name ID 2 and 17 have firmly established meanings, the current implementation of fontKit is creating errors, and this is a decent way to fix them without causing additional errors. Am I misunderstanding something?

[ptoussai]

https://learn.microsoft.com/en-us/typography/opentype/otspec180/fvar

Values of 2 or 17 can be used; otherwise, values must be greater than 255 and less than 32768.

Name IDs 2 and 17 have an established meaning, but they can also be referenced by the fvar table.

If anything, the fix is a bit too broad as it makes these Name IDs accessible to other tables, such as feat, but I don't see the need for restriction.

Popular font authoring software already make use of this, and Fontkit should support it.