Minor Kerning Interpolation: The return of the kerning monster

[VivaRado]

Ok, here is the preview build (sorry it took so long) preview_build_2.zip:

In the preview, there are two fonts:

• Normal:
  • Here compiled with deducted in (index_normal_deducted.html):
    • We don't ask any exaggeration and "AVA", "AUA", "AWA" are ok.
  • Here compiled with standard in (index_normal_standard.html):
    • We don't ask any exaggeration, but "AVA", "AUA", "AWA" are NOT ok.
• Exaggerated:
  • Here these values are exaggerated and compiled with deducted in (index_exaggerated_deducted.html):
    • All values exaggerate and "AVA", "AUA", "AWA" are ok.
    • Group to Group:
      • thn (thin): pos @_A @_e1 200;
      • thn_it (thin italics): pos @_A @_e1 -234;
    • Group to Letter:
      • thn (thin): pos @_A AE 233;
      • thn_it (thin italics): pos @_A AE -252;
    • Letter to Group:
      • thn (thin): pos Hbar @_A1 -221;
      • thn_it (thin italics): pos Hbar @_A1 215;
    • Letter to Letter:
      • thn (thin): pos OE AE 220;
      • thn_it (thin italics): pos OE AE -211;
  • Here these same values compiled with standard in (index_exaggerated_standard.html):
    • All values exaggerate, but "AVA", "AUA", "AWA" are NOT ok.

In short:

• with the standard libraries, we get the values to exaggerate on thin_it and thin (Ae AÆ ŒÆ), but kerning in some other pairs gets affected.
• with the deducted libraries, we get the values to exaggerate on thin_it and thin (Ae AÆ ŒÆ), and kerning in all other pairs is ok.

PS. I made the report like a movie sequel. PPS. The font now has all the kerning pairs, not just a subset. (Huge milestone, thank you!)

[behdad]

@anthrotype, something to look into together?

[VivaRado]

Happy New Year!

The values are missing because of OTLOffsetOverflowError in otBase ( in contrast fontlab compiles them and there is no overflow loss)

Before that, in otlLib/builder.py : buildPairPosClassesSubtable all the GPOS data apear normal.

The data also appear normal in addOpenTypeFeaturesFromString, as self.features are all good.

But when the TTFs are generated they lose values (pos and classes get clipped), right before the final variable gets collected from the temp.

[VivaRado]

In otBase: raise # Oh well... doesn't prevent (my bad)

P.S. Ignore the deducted, seems to me that this is the only problem left to solve.

Here you can see that for example @_H @_G values are not present in resulting.fea Also both files are quite close in terms of size, that is why i believe something is getting clipped. fea_result.zip

[VivaRado]

Hello, another issue I found is that if I have previously split the FEA into subtables:

    pos @_A @_y 26;
    pos @_A @_z 49;
   subtable;
    pos @_A @_Thorn 48;
    pos @_A @_ampersand 23;

after the otBase, or otTables It adds additional subtable splits. If i split at 49 - instead of 50 the splits fall into place. But it seems to me that there should be a removal of "subtable;" strings before passing to the addOpenTypeFeaturesFromString

    pos @_A @_y 26;
    pos @_A @_z 49;
   subtable;
    pos @_A @_ampersand 23;
   subtable;

A note about sorting also. In Fontlab, there is a warning, where if you have definition of a pos without class before a class. So when i sort the FEA i do it by counting how many classes "@_" in each pair, and those go first. That is why Group to Group, Group to Letter, Letter to Group, Letter to Letter.

sorted(fea_lines, key=lambda x: x.count('@_'))

[VivaRado]

So far i understand that the issue is not with the Varlib or Fontmake or Fonttools.

The issue is with opentype itself. (Might sound grandiose but its true.)

If you want to explicitly set the classes:

@_H = [ H, Eta]

It will compress and rename the class to

@_Eta = [ Eta, H]

Just because E is before H... and so it goes to all other aspects.

[VivaRado]

Seems like if the GG, LG, GL kerning values, don't listen to your kerning, you can pass LL at the end of the kerning FEA and the values get appropriately "fixed". But again that is because of how Opentype Features work?!, if you have a lot of values one might think... but i have just 4500 pairs after TYPL Compress.

Seems to me that there must be some sort of obscure balance between GG,LG,GL so the pairs result without too many subtable breaks that create misbehaving pairs.

To bypass this "obscure balance" i see that if i just pass the kerning for the pairs that ignore it - they don't ignore it completely, they just don't move enough - its crazy i know... - as Letter to Letter at the end of the FEA, the compile passes and the kerning is changed and behaving.

Again, this is not an issue with FontTools, i can confirm the same behavior in Fontlab - where another bizarre thing happens in addition. The preview panel with kerning compiled, ignores the values, but the metrics window shows them just fine!

The solution of passing the fixes as Letter to Letter, is not bad unless you first compress the GG,GL,LG to the maximum - because too many fixes to LL and you will end up with 8000 pairs in no time! )))

[VivaRado]

I don't know if this is relevant: https://github.com/VivaRado/greek_kerning_bug Also i have noticed that other fonts do kerning with sidebearings, but if you want to maintain glyph sidebearings to the width of the glyph, which to me makes more sense, and pass the values to the pos for kerning instead, it gets tricky in all sorts of ways one is that kerning values like cross language system or even when a language system keeps its own classes fail aswell or are inconsistent. But again this is not a problem of fontmake.

[behdad]

@anthrotype any idea if anything needs to be done here?

[anthrotype]

no idea... 🤔

[VivaRado]

Seems like everything is in order. Thanks a lot for that solution @behdad