Gasp write support broken, opentype.js cannot read the fonts it creates

[Balearica]

Support for the gasp table was added in #595, which ostensibly included both read and write support. I cannot speak to the quality of the read function, as I am not familiar with the gasp table, however the write support is definitely broken. It appears that any font file generated by opentype.js with a gasp table will be broken, and cannot be re-imported.

Code At Issue

The write function attempts to iterate over a constant (gasp.numRanges) as if it were an array. As a result, any code inside the loop will never run, and the gasp table will be broken.

opentype.js/src/tables/gasp.mjs

Lines 37 to 40 in 811a9c2

	for (let i in gasp.numRanges) {
	result.fields.push({name: 'rangeMaxPPEM', type: 'USHORT', value: gasp.numRanges[i].rangeMaxPPEM});
	result.fields.push({name: 'rangeGaspBehavior', type: 'USHORT', value: gasp.numRanges[i].rangeGaspBehavior});
	}

While a broken gasp table is not a big deal per se, opentype.js currently throws an uncaught error if the gasp table fails to parse. Therefore, opentype.js cannot read the fonts it writes that include a gasp table.

Reproducible Example

This can be reproduced with any font with a gasp table, including many of the fonts in the test directory. For example, the Changa-Regular.ttf file works. Simply load the font, convert it to an array buffer with .toArrayBuffer(), and then attempt to parse that ArrayBuffer using opentype.parse.

Suggested Fixes

I think there are several different aspects to this issue. I will try and write a small patch that prevents the crashing tonight. However, I have no knowledge of or interest in the gasp table, so don't plan on working on gasp support past that point.

1. Patch the bug in the gasp write function

It looks like the author was trying to iterate over gaspRanges (an array) rather than numRanges (an integer). I will confirm this change stops the error from being thrown and submit as a PR.

2. Add automated tests for the gasp write functions

While the PR that included the gasp write function did include some tests for reading gasp tables, it included no unit tests for writing gasp tables. I think anybody adding a new feature of this nature should, at the very least, add a test to confirm that their read functions can parse the tables produced by their own write functions.

3. Prevent issues with optional tables from throwing an uncaught error

The issue with the gasp write function being broken would not be a big deal if the only impact was that the gasp table could not be re-imported. This only breaks opentype.js for as many fonts as it does because failing to parse gasp correctly throws an uncaught error, which prevents the font from being read. Wrapping optional tables in try blocks would prevent this going forward. I think this is worth pursuing even after the issue with gasp is resolved, as the chances that some parsing function has an issue in the future seem quite high, especially as opentype.js continues to add support for more and more tables (and therefore increase surface area).

Your Environment

• Version used: e9c090e
• Font used:
• Browser Name and version:
• Operating System and version (desktop or mobile):
• Link to your project: