Error 0x963a: ClassDef format must be 1 or 2 since upgrading from 1.3.3 to 1.3.4

[adriaanmeuris]

Expected Behavior

The attached file loads without issues on opentype.js@1.3.3

Current Behavior

It fails to load with opentype.js@1.3.4 with error x963a: ClassDef format must be 1 or 2.

Steps to Reproduce (for bugs)

This is the source font file: 96025-ld-soft-serif.ttf.zip

import { load } from "opentype.js";

load("src/96025-ld-soft-serif.ttf", function (err) {
  if (err) {
    // when using `opentype.js@1.3.4`
    console.log("Font could not be loaded: " + err.message);
  } else {
    // when using `opentype.js@1.3.3`
    console.log("Successfully loaded");
  }
});

Your Environment

• Version used: 1.3.4
• Font used: see file attached
• Browser Name and version: Google Chrome @ 108.0.5359.124
• Operating System and version (desktop or mobile): MacOS Ventura 13.1

[Connum]

I looked into this and can confirm that the provided font file loaded before 9cfd2a7 and stopped working with that commit.

What I don't understand yet is why it ever loaded before that in the first place. Because in fact that font file seems to have a faulty definition of a ClassDef table format of 0. While the https://www.microsoft.com/typography/OTSPEC/chapter2.htm states that glyphs can be assigned to a class and automatically fall back to a class of 0, the ClassDef table format can indeed only be of either 1 or 2. Opening the file in another font tool confirms that issue: Unknown class table format 0.

The question is how do we want to handle wrong format definitions? I think it would be better to output a console warning about it, but proceed loading the font ignoring that table nevertheless. What do you think @ILOVEPIE?
It would also be interesting to know why it loaded before,

[ILOVEPIE]

@Connum I agree with your conclusions on this one, we should print a descriptive error in cases like this and ignore the bad data.