I temporarily reverted my download to Pali version 3.0 because that is the latest version I could find where the kerning works in PagePlus, Affinity Publisher (presumably), and LibreOffice.
The pairs are definitely being exported and are present when I reopen the *.otf.
Maybe just too many pairs or too many subtables (9). I will try to diagnose the bug and fix it.
It is related to Subtables. If move Subtable Caps to the top, those work, and so does Subtable Hyphen, but not Subtable lc.
If I move the lowercase and pcap tables up, the hyphen pairs still work OK, but neither lowercase pairs nor petite caps pairs are kerned in PagePlus.
I’ve opened version 3.44 but kerning didn’t even work in FontCreator, so maybe it is broken?
Can you send me the project file, so I can look into this?
Thanks. I have sent the project file for Pali Regular.
The original contained a table for lowercase/Uppercase pairs, which had a lot of class overlaps when I merged the subtables, so I deleted that subtable.
Merging the other subtables showed up some duplicate pairs, which were stripped on compiling the lookups.
This is the best that I have managed thus far. All but smcp, pcap, and subs/sups pairs are working now.
Further merging of subtables or changing the order seems to make no difference.
Do send me this project, and I will look into it.
I have sent you the project file, and an older version that mostly works in PagePlus X9.
Maybe it is just something we have never fully understood, but I think I now understand the problem.
Class based kerning is stored as a two-dimensional array as sequences of two class values. This array also includes class0, which represents all glyphs that are not assigned to any of the used classes. This class0 is then matched, so subsequent sub tables will never be processed. We might need to change some things and update the manual if this is indeed what is happening…
Your efforts are much appreciated. When I started using FontCreator 4.0 I never imagined there was so much to the process of creating a robust font with comprehensive glyph coverage.
It is slightly different. With a class based positioning subtable, a match is found it either the first or second glyph is found (or both of course). If they both do not exist in the subtable, then it will proceed in the next subtable(s).
Some more testing revealed that my last statement is incorrect.
These are my findings:
With a class based positioning subtable, a match is found if the first glyph is found. The second one seems to be irrelevant.
So this will work:
lookup PairAdjustment1 {
subtable Subtable1 {
pos @KernClass_V @KernClass_A <100> <0>;
pos @KernClass_W @KernClass_U <200> <0>;
pos @KernClass_X @KernClass_o.subs <300> <0>;
}
subtable Subtable2 {
pos @KernClass_Y @KernClass_o.subs <-250> <0>;
}
}
And here the rule in Subtable2 is never applied, as class KernClass_Y is among the first class definitions of Subtable1:
lookup PairAdjustment1 {
subtable Subtable1 {
pos @KernClass_Y @KernClass_parenright <75> <0>;
pos @KernClass_Z @KernClass_S <400> <0>;
}
subtable Subtable2 {
pos @KernClass_Y @KernClass_o.subs <-250> <0>;
}
}
The user manual already mentions it, but somehow it is easily overlooked:
It is important to realize class based kerning is stored in a two dimensional array; which is made out of first glyph classes and second glyph classes. If a glyph exists in a first glyph class, it should never be included in another first glyph class, as such overlapping classes are not allowed for class based kerning. Same goes for second glyph classes. Due to the nature of a two dimensional array, if a specific pair is not included in the pair list, it will still be stored in the pair positioning lookup. All glyphs that are available in the first glyph classes will cause the text processing engine to stop looking for pairs in subsequent sub lookups.
How can we improve the user manual?
I don’t think there is any problem with the manual. I already understood that class overlaps should be avoided, but I still do not understand why the Petite Capitals and Super/subscript subtables are not being processed.
Does this make things more clear?
With text “BAYOZY” only pair OZ will be processed in subsequent subtables. Even though BA, YO, and ZY are not defined as pair positioning rules, they are still matched with the matrix.
This update provides better validation when compiling feature code. The proofing tool also shows when a class based pair positioning match is found. That can be hidden with the “Compact” option.
FontCreator 13.0.0.2651 (64-bit)
Let us know your results.
Thanks. So at least if it something wrong with my fonts, I can fix it; not a bug in PagePlus X9 over which I have no control. The syntax check will help a lot to debug my fonts.
I need a rest before I can tackle this.
I was unable to get anywhere with this. I even tried deleting the kern feature and running the autokern wizard. That produced 395K kerning pairs, with a lot of junk pairs, but no kerning pairs for Small or Petite Capitals, nor for Caps paired with super/subscripts.
For each class based pair adjustment positioning subtable, you must ensure each glyph is added to (at most) one pair positioning first class and to (at most) one pair positioning second class.
You can visualize it as starting with a huge matrix with only single glyphs as both columns and rows. Then you start merging several columns, so they become a class. Then you do the same for the rows.
And of course for this to work, the right side-bearings of glyphs in a first class, must be very similar. Likewise for the left side-bearing for glyphs in second class.
I believe other font editors facilitate this process by glyph related options that allow you to specify the main or leading glyph to form such glyph classes for pair positioning.
All this seems to be saying is repeating what I thought I already understood, that glyphs should not overlap, but I already did that.
Another bug is that pressing Cancel while syntax checking does not stop it. The dialog greys out only, but the syntax check continues until it is complete.
Yes, the glyphs in the glyph classes must not overlap. If they do, you will see the accompanying compiler warning(s).
This will be fixed with the next upcoming update.