ligature seems to not work correctly

Using Zilla-Regular (otf version, found here: https://github.com/mozilla/zilla-slab/tree/master/OTF_release files) on a page with opentypejs shows the font “doing the right thing” with the double slash in Moz://a as a text element, but when obtained through opentype.js, shows incorrect ligature of the // sequence (there should be a ligature, but there isn’t).

Screenshot of a a page with a <p>Moz://a</p> and a canvas with the same string rendered using OpenType.js:

Code used:

      opentype.load(ZILLA_FONT_REGULAR, function(err, font) {
        if (err) {
          return console.log(err);
        } else {
          var ctx = document.getElementById('canvas').getContext('2d');
          var path = font.getPath('Moz://a', 0, 150, 72, {
            features: true,
            kern: true
          });
          path.draw(ctx);
        }
      });

(ZILLA_FONT_REGULAR is a data-uri for the font linked to above)

[fpirsch]

These tables are so complex that, not only are they a nightmare to parse and to write, but nobody seems to use them correctly :-p

[fpirsch]

Hi @fdb and @Jolg42 GPOS lookup 9 and GSUB lookup 7 are actually special extended-offset tables used to break the 32-bit offset limit in big fonts. It is a container for other lookup tables.

Currently, GSUB lookup 7 support is partial (the table is parsed but not used, and not written), and GPOS lookup 9 support is totally absent.

In fact GPOS support was done long ago in a hurry and needs serious refactoring (it is very primitive and inconsistent with what is done for GSUB). I later wrote the GSUB support with this in mind: layout.js, table.js and parser.js are intended to serve both GSUB and GPOS (and GDEF if needed).