Kerning not outputting as previewed

Post Reply
Matthew-Fenton
Posts: 2
Joined: 24 Apr 2021

Kerning not outputting as previewed

Post by Matthew-Fenton »

Hey Tim, we’ve ran into a few errors regarding Kern-on, we’ve found that when Kern-on is automatically previewing kerning pairs – this ends up being different to the outputted kerning. See screenshots below.
Screenshot 1: Previewed kerning pairs
Screenshot 2: Outputted kerning pairs
We’re finding that this is happening with diacritical marks, vs overhanging letters such as the TVW, where the right side is being crushed and not taking the value being applied by the models on the left-hand side – see the 2nd screenshot. TïTîT TöTôT etc
The only fix we’ve managed to find is by setting up the affected glyphs as independent pairs which feels very long and is often easier to kern outside of Kern-on manually.
Is there a reason this is happening and is there a fix to make the process easier?
Cheers!
Attachments
Outputted kerning pairs.png
Outputted kerning pairs.png (475.36 KiB) Viewed 6374 times
Previewed kerning pairs.png
Previewed kerning pairs.png (256.6 KiB) Viewed 6374 times
User avatar
SCarewe
Posts: 103
Joined: 23 Apr 2021

Re: Kerning not outputting as previewed

Post by SCarewe »

Without knowing for sure the real reason for this, I am assuming this is due to the principle Kern On follows when kerning: Significance in real-world application. Meaning, Kern On will not kern every pair under the sun, but prioritise kerning pairs that actually occur in the real world (based on hundreds of thousands of processed real-world text documents in various languages). There is, simply put, a cut-off after which kerning pairs with lower occurance than others will not be kerned in order to conserve file size.

So, whenever you find yourself wondering why a certain pair isn't kerned, ask yourself: When, ever, will a combination such as êT actually occur?

I seem to remember there was some way of getting Kern On to output all kerning pairs that it knows, by setting the kB size to 0. Then you will need to take care of subsetting the kerning yourself, though.
User avatar
Tim Ahrens
Site Admin
Posts: 407
Joined: 11 Jul 2019

Re: Kerning not outputting as previewed

Post by Tim Ahrens »

Thanks for the help, Sebastian!

Matthew, are you using the latest version of Kern On? (Currently it’s v 1.18 from 20 Nov 2022.) Which kerning size (in kB) were you using? Have you tried increasing it?

To refine the explanation:

• Kern On only kerns pairs that it thinks can occur in real life. You can find this list if you right-klick on the .glyphsPlugin file, choose “Show Package Contents”, then it’s the file /Contents/Resources/pair_frequencies.txt. As you can see, ëT is in fact in the list, ranked 24,784th among the Latin letter-letter pairs, with a priority value of 42. The fact that it is in the list corresponds to the fact that it is autokerned in the live preview (while Kern On is running). If it was not in the list at all then it would not be autokerned at all, and none of the Model/Auto/Ind segments would be activated (but you could explicitly switch it to Auto, a so-called user-set autopair).

• As the final kerning is generated, Kern On has to omit some pairs so as to stay below the kB limit you give. It will omit those pairs that have a low priority value and/or a small error if not exported. This can lead to pairs “loosing” their kerning entirely, or getting the wrong (potentially too tight) kerning from their class.

So, in your case, some pairs such as ëT made it into the list of autokerned pairs but not into the final kerning (or with a wrong class kerning value). I am aware that it’s not perfect if you don’t have a preview of the final output but it would technologically difficult to achieve as it takes too long to compute. We’d have to find out whether in the end, the pair will have the exact value, or no kerning (because it had to be omitted), or a somewhat wrong value (because it made it into a kerning class and the necessary glyph-glyph exception was omitted). Kern On would practically have to do the whole finalization, which takes a long time, practically as long as the progress bar you can see during finalization.

As Sebastian pointed out, we have to live with a final kerning that omits the not-so-relevant pairs. Kern On really tries hard to get as much relevant kerning into your give data size but if you use test strings like TïTîTöTôT that include extremely unlikely pairs then you will encounter flaws.

Hope this helps, I’m open to suggestions.
Matthew-Fenton
Posts: 2
Joined: 24 Apr 2021

Re: Kerning not outputting as previewed

Post by Matthew-Fenton »

Many thanks, Sebastien and Tim!

That absolutely makes sense, we just wanted confirmation that this is what was happening. Thanks for clearing up and good to know how to find the ranking of specific pairs and definitely raises questions about how much kerning we need if it's not that likely.
Post Reply