EB Garamond's kerning data not readable by OpenType.js

[Typogram]

Describe the bug
Download the ttf from https://fonts.google.com/specimen/EB+Garamond. use it as a test. The fonts have kerning info, and can be used as regular desktop fonts with proper kerning. However, OpenType.js can't read its kerning data. letter AV kerning should be -140, but OpenType.js returns 0

This may also apply to other Google Fonts like: DM Serif Text

To Reproduce

1. go to https://codepen.io/wendyz/pen/PoQJyoX?editors=0011
2. open the console
3. OpenType.js return AV Kerning to be 0, where it should be -140
   

When I open the EB Garamond font with Robofont, I can see there is kerning info in the kern center. AV kern should be -140

However when I download EB Garamond 8pt (another version) from the type designer's Bitbucket repo, OpenType.js output proper kerning for that version of EB Garamond font.

Expected behavior
Get correct kerning info from OpenType.js, like the EB Garamond version downloaded frrom bitbucket: https://bitbucket.org/georgd/eb-garamond/downloads/

Additional context
Add any other context about the problem here (OS version, browser, printer…)

• OpenType.js Version used: 1.3.4 https://github.com/opentypejs/opentype.js/
• Font used: EB Garamond
• Browser Name and version: Chrome
• Operating System and version (desktop or mobile): Mac and Windows
• Link to your project: https://codepen.io/wendyz/pen/PoQJyoX?editors=0011
• Old issue that is related but resolved: Support for GPOS table parsing opentypejs/opentype.js#19
  I also reported this issue to OpenType.js: OpenType.js can't read Google fonts' kerning, eg. EB Garamond opentypejs/opentype.js#515

[kenmcd]

Does not appear to be an issue with the fonts.
It appears to be an issue with OpenType.js not reading all of the kerning data properly.
In EBGaramond08-Regular the AV kerning is in the first lookup.
In EBGaramond-Regular and DMSerifText-Regular the AV kerning pair is in the second lookup or subtable.
And the fonts work fine in various applications.
So it appears this needs to be resolved in OpenType.js

[sumon1991]

https://github.com/behdad/fonttools/ has support for this in python, so basically the feature request is to port the fontTools code to opentype.js

[Typogram]

https://github.com/behdad/fonttools/ has support for this in python, so basically the feature request is to port the fontTools code to opentype.js

Thanks for the quick reply and the information! Can you point me to part of the code in https://github.com/behdad/fonttools/ that is related to this? I want to take a stab at porting it to OpenType.js but need some directions :)

[Typogram]

Does not appear to be an issue with the fonts. It appears to be an issue with OpenType.js not reading all of the kerning data properly. In EBGaramond08-Regular the AV kerning is in the first lookup. In EBGaramond-Regular and DMSerifText-Regular the AV kerning pair is in the second lookup or subtable. And the fonts work fine in various applications. So it appears this needs to be resolved in OpenType.js

Is Google Font consistently putting kerning data in the same place, or it depends font to font?
By any chance there is a font script to modify the font so that OpenType.js can read the kerning data? I am looking for an alternative to solve my problem in case OpenType.js can't resolve this quickly :)

[Typogram]

Does not appear to be an issue with the fonts. It appears to be an issue with OpenType.js not reading all of the kerning data properly. In EBGaramond08-Regular the AV kerning is in the first lookup. In EBGaramond-Regular and DMSerifText-Regular the AV kerning pair is in the second lookup or subtable. And the fonts work fine in various applications. So it appears this needs to be resolved in OpenType.js

What is your method of checking the font and see where the kerning data is stored at?
Regarding to second lookup, is this piece of code from OpenType.js related to what you are saying? It seems they do support lookup type 2?
opentype.js/src/tables/gpos.js
opentype.js/src/position.js

[kenmcd]

I used a font editor to look at what was there.
But that really does not matter.
The fonts are fine.
There is no error in the fonts.
The problem appears to be that OpenType.js cannot properly process these fonts' valid kerning code.
All three of these fonts are from different designers - each using slightly different approaches, but using entirely valid kerning code.
So there is nothing that can or will be done here.
The problem needs to be fixed in OpenType.js.
Have them explain why it returns the AV kerning as 0.

[Typogram]

@kenmcd I understand that the font has kerning data, and works fine with other program, that is what I said in the issue request.
I am just trying to find a way to check how the kerning data was stored differently in an effort to find a fix for OpenType.js, or in short term, modify the font so it's kerning info can be read by OpenType.js. You said it is because the kerning data was stored in lookup 2 so I wonder what font editor do you use to check that or comfirm that. OpenType.js has code to read GPOS lookup type 2 kerning info, so either the code is malfunctioning, or the font kerning data wasn't stored there, I am trying to narrow down the problem area and proactively sovle the issue here.