Parsing and writing support for variable font tables fvar, STAT and avar

[Connum]

Description

• add missing encode.F2DOT14
• add encode.FLOAT as a wrapper to encode.FIXED when handling actual float numbers
• adapt fvar writing to new platform-agnostic names structure (see Preserve platform specific names in fonts. #542)
• fix fvar table not being written (fix fvar table is parsed and can be generated, but is never actually written to a file #573)
• add parsing and writing support for STAT
• add parsing and writing support for avar
• add stub for gvar parsing and writing

Motivation and Context

This PR lays the groundwork for variable fonts support. Actual coordinate scaling and normalization (see https://learn.microsoft.com/en-us/typography/opentype/spec/otvaroverview#CSN) for rendering is not yet implemented, but several tables needed for supporting it can now be parsed and written.

I decided against also implementing gvar, because it introduces a set of new concepts/data types and seems to be the most complex of them. That would have bloated the PR even more.

Further resources for future rendering implementation:

• Axis mapping in variable fonts: setting up an avar table in a designspace file arrowtype/blog#6
• https://www.axis-praxis.org/samsa/

How Has This Been Tested?

Loading and saving different variable fonts, added tests.

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I did npm run test and all tests passed green (including code styling checks).
• I have added tests to cover my changes.
• My change requires a change to the documentation.
• I have updated the README accordingly.
• I have read the CONTRIBUTING document.

[yne]

very nice addition 👍

[yne]

LGTM 🚀
don't forget to fix the import paths before merging 👍

[Connum]

You'll have to approve again before I can merge.
Is there a good way to catch missing file endings in imports, without having to manually test it in browser context? Maybe a linting rule?

[yne]

@Connum I rebase-squashed your connum/feature/variable-font-tables on upstream/master + fixed lint + minor STAT->stat renaming

All lint+test are now passing. You can merge when you are okay (I can't since I'm the last committer)

[yne]

Is there a good way to catch missing file endings in imports

Node / Deno implicitly lookup import with .js suffix, browser don't, so either we

• add a eslint-plugin-import dependency + "import/extensions" : ["error", { "js": "always"}] rule

• run a chrome in CI that <script type=module>import 'src/opentype.js'</script>

[Connum]

I can't approve because I'm the PR author! @ILOVEPIE? :)

[Connum]

• add a eslint-plugin-import dependency + "import/extensions" : ["error", { "js": "always"}] rule

I'm all for that!

[Connum]

I just added the plugin and configured it, but strangely while VSCode does indeed show red lines under missing file extensions for import statements, the npm run lint command does not. When I change "always" to "never", it shows errors for all other import statements, however. I stumbled upon import-js/eslint-plugin-import#2319 which brought me to https://github.com/satazor/eslint-plugin-import-esm - but it's exactly the same, with VS Code doing what it's supposed to do, but the lint command failing. I have no clue what's happening here!

[yne]

maybe the best testing would be to have in CI a chrome-headless test that import the /src/opentype.js :)

[Connum]

I just added #584 with a custom eslint rule for enforcing file extensions in import paths.