I noticed MS Word (for Mac, 15.32) doesn’t kern my Greek, even though kerning is switched on and working for the Latin:
Note how /K/o/ and /T/n/ are kerned but /Kappa/alpha/ and /Gamma/eta/ are not.
Meanwhile, Font Book does kern the Greek as expected:
Might this have to do with the fact that I use mostly the same kerning classes across Latin, Greek, and Cyrillic? If so, why does Glyphs not decompose those into separate kerning classes upon export?
Tosche was so kind as to update his script so it runs under Glyphs 3. Unfortunately, it doesn’t fix the issue. The Greek kerning looks fine in Font Book and Pages but fails in Word.
(I should probably upgrade to Office 365 at some point…)
GPOS support is very limited in Word. There are hacks like registering the kern lookups in dist as well. But I do not recommend them because they may break the font elsewhere.
I’m not sure splitting kerning by script is still a high recommendation nowadays.
Also, continuing the discussion from the repository, I don’t think you can auto-run a script as part of font export (there might have been such a custom parameter but I don’t remember). You can export fonts from a script though.
With this file, the kerning doesn’t seem to work at all. I’m using the latest MS Word (16.59). We should get paid for all the hassle Microsoft is causing with their deficient OpenType support in Office apps.
Alright, apparently EB Garamond fails in the same way as Ysabeau in MS Word, whereas the /Gamma/omikron/ is clearly kerned when viewed in Pages. I will definitely blame it on Word, then, and let the issue rest for the moment.
I have complained about other Word issues on typedrawers.com and actually got some reaction from Microsoft. The kerning issue — as it is still ongoing — should maybe be addressed there too.
It’s so frustrating that MS apps still don’t abide by the OpenType specifications that are documented on their own site (kern - Kerning (OpenType 1.9) - Typography | Microsoft Docs). Font production would be so much easier, if we wouldn’t have to constantly have to deal with Microsoft short comings.