GSUB lookup table type 7 subtable format 1

[st0nerhat]

Description

In featureQuery.js:chainingSubstitutionFormat3

• Modify var types of subtable, lookup, and substitutionType to be lets so they can be mutated in the next step.
• Detect substitution type "71" which means lookup table type 7 and format 1.
• When detected, mutate the substitution type and lookup method based on the linked extension subtable
• Finally update the subtable variable to be the extension table
• Throw an error if the chained substitution type is not handled. This will avoid fonts that use chaining substitutions from silently rendering incorrectly if they use an unhandled changed substitution.

In featureQuery.js:FeatureQuery.prototype.lookupFeature

Same changes as above.

Motivation and Context

Addresses issue #415

GSUB tables have a lookup table type 7 called the Extension Substitution Subtable. Only one format officially exists (format 1).
See the OpenType spec page.

Per the spec, Extension tables are used in fonts that use a large number of substitution subtables. Fonts for scripts where letters are connected are a situation where many substitutions are needed.

How Has This Been Tested?

So far I have tested this on 3 custom fonts in my library, one of which contains type 7 lookup tables and 2 that do not. Unfortunately I do not have the license to upload these fonts in the PR.

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.

[Connum]

Unfortunately I do not have the license to upload these fonts in the PR.

The tests don't use actual font files to run (see 3177c13 for example), so it would be great if you could add (a) test case(s) to your contribution!

[Connum]

requires test(s)

[Connum]

I just added a PR FilamentGames#2 to the feature branch that adds a test for this parsing feature. @st0nerhat, could you please merge that so we can get this PR merged?

[Connum]

As I provided the test, a different reviewer should make a review as well, so I tagged @ILOVEPIE

[ILOVEPIE]

Looks good to me, apart from the fact that we're still uncertain on the tests/no examples in the microsoft documentation, perhaps we should check how libfreetype handles it?

[Connum]

Looks good to me, apart from the fact that we're still uncertain on the tests/no examples in the microsoft documentation, perhaps we should check how libfreetype handles it?

The functionality is relatively straight-forward. I tried looking at libfreetype, but I didn't know where to look exactly. In my opinion, the test that we have now should be sufficient.

[Connum]

I haven't come across a better stripped down example for a test, but I didn't come across any problems either so far, so I'm merging this now.