Missing Autopairs / Unkerned Pairs

Post Reply
Lewis MacDonald
Posts: 1
Joined: 12 Aug 2021

Missing Autopairs / Unkerned Pairs

Post by Lewis MacDonald »

Hi Tim,

I've been testing the trial for a little while now – seems like a great tool! I'm having a bit of a problem though, with lots of pairs being left unkerned after telling the engine to 'kern-on'.

Many of my pairs, involving certain accented glyphs, or certain symbols, aren't being set to 'Auto' by default; in fact, none of the 3 pair type options of 'Model', 'Auto', or 'Ind' are selected by default.

I can manually set pairs to 'Auto', and, when I do, the engine kerns them. But it would be laborious to manually set every one of these pairs to 'Auto' – so I'm wondering if there is a way to set every possible kerning pair to 'Auto'?

I can get around this for the accented glyphs by limiting the kerning to something low like the default 36kB, forcing the accented glyphs to take the kerning group of their base glyph. But the engine still won't kern pairs which include certain symbols (e.g. 'A→') unless they have been set to 'Auto'.

FYI, neither of the glyphs in the pairs is set to 'No Kerning' (I've tried 'Standard Kerning' and 'Special Spacing'), and I currently have 54 models.

Many thanks in advance, have a great day!
User avatar
Tim Ahrens
Site Admin
Posts: 164
Joined: 11 Jul 2019

Re: Missing Autopairs / Unkerned Pairs

Post by Tim Ahrens »

Thanks for your feedback!

If a pair doesn’t have any of the ‘Model’, ‘Auto’, or ‘Ind’ selected that means it is ‘not in the system’, or ‘ignored’. Kern On has a built-in list of Unicode character pairs, which is then expanded by applying the OT features in the font, all other pairs are ignored. There are some details in the Under the Hood video from 1:40 to 3:40.

So, the question is, why aren’t your pairs in the system as they should? If the pairs (i.e. both glyphs) have Unicode values but they are ignored then that means you may have a different view of which combinations/pairs are worth kerning, or you are using rare characters which I didn’t include in the list. In either case, just let me know, I’m open to discussion.

If the missing/ignored pairs include glyphs that do not have Unicode values, maybe you simply haven’t implemented them in the features yet? Just add the code and they should become auto pairs as you start Kern On again. (Note that changes to the feature code, like other major changes to the font, should be made while KO is sleeping.) In case they are definitely implemented via OT features, there is a certain possibility that my current implementation is not 100% complete with respect to the application of complex contextual substitutions. Glyphs 3 handles them in a different way than Glyphs 2, and it’s still subject to changes, so Kern On has to adapt. Just let me know if you think you have hit a case of incomplete application of contextual OT features, and I can have a closer look.
Fanny Hamelin
Posts: 1
Joined: 07 Sep 2021

Re: Missing Autopairs / Unkerned Pairs

Post by Fanny Hamelin »

Hi everyone! I've been using Kern On for two weeks now, and it seems to be a great tool that I will continue to use.

I do have a small question about the kerning pairs that are generated at the export.
After a first round of kerning with Kern On, I generated the kerning and printed some proofs. I noticed that some pairs were not kerned, as example among others: /V/C.sc while /V/O.sc was kerned.
However, when I restart Kern On and type this pair /V/C.sc, it kerns itself correctly.

So there is something I don't understand. Is it because the kerning size generation limitation is too low? Is it because I hadn’t typed the pair while Kern On was running? Has anyone else had this issue as well? All my OpenType is done.

Thanks in advance for your help
User avatar
Tim Ahrens
Site Admin
Posts: 164
Joined: 11 Jul 2019

Re: Missing Autopairs / Unkerned Pairs

Post by Tim Ahrens »

If the pair does not show up after generating the full kerning although it is kerned while Kern On is running then that means it had to be removed in the last phase of finalization because it was considered less important than other pairs.

/V/c is not very frequent (currently ranks 33021 in the list), and /V/C.sc, which is derived from it via the OT feature(s) gets an even lower priority, so that’s a likely scenario. IMHO not having kerning for /V/C.sc in the font is not a disaster, though.

If you increase the kerning size limit then /V/C.sc should be included in the final kerning.
Post Reply