search

google / fonts

Font files available from Google Fonts, and a public issue tracker for all things Google Fonts
https://fonts.google.com
17.83k stars 2.6k forks source link

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

Open Typogram opened 2 years ago

Typogram commented 2 years ago

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 image

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 image

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…)

kenmcd commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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.