Class kerning reliability

Post Reply
Morula Type
Posts: 8
Joined: 03 May 2022

Class kerning reliability

Post by Morula Type »

Hi Tim,

I love KernOn and lately I'm using it more and more to finalize my projects. That said, I'm finding some conflicts that make me doubt on the reliability of the final results, especially within kerning classes.

The main problem is with glyphs that have the same class but different contours, especially when kerning size is set below 10Kb. In the images I'm attaching, for example, you can see how de-cy and De-cy have the same left group, resulting in an incorrect kerning between T and de-cy, obviously. Same goes for D and Dcroat, inexplicably having different right groups, or other glyphs having the same group as punctuation glyphs like colon, which results in hyphens and dashes getting too close or crashing into them.

I understand the storage need underlying the fitting of many different shapes under a single class, but I think that very common pairs (like UC + LC) must be given higher priority than, say, (period + percent) or (dcaron + 7), which are hardly ever going to be used together.

I've seen that this problem has been brought up before in this forum and you replied that the exported instances would not have had any issue, but in my case the exported file is visually the same as in the editor, so the problem persists. If .otf instances ought to be different and correct, do you care to elaborate on why/how?
This is truly the only thing I can criticise of KernOn, but it's also what is preventing me from finalizing all my files with it, so I hope there's a solution I'm not seeing!

By the way, love the plugin, keep un the great work!
Attachments
Screenshot 2022-05-04 at 10.53.15.png
Screenshot 2022-05-04 at 10.53.15.png (50 KiB) Viewed 11413 times
Screenshot 2022-05-04 at 10.53.21.png
Screenshot 2022-05-04 at 10.53.21.png (39.71 KiB) Viewed 11413 times
Screenshot 2022-05-04 at 10.53.31.png
Screenshot 2022-05-04 at 10.53.31.png (141.35 KiB) Viewed 11413 times
Morula Type
Posts: 8
Joined: 03 May 2022

Re: Class kerning reliability

Post by Morula Type »

Oh, also: why are braces and other important glyphs set to "no kerning" by default?
User avatar
Tim Ahrens
Site Admin
Posts: 404
Joined: 11 Jul 2019

Re: Class kerning reliability

Post by Tim Ahrens »

Thanks for your feedback!

Here are some comments:
Morula Type wrote: 04 May 2022 The main problem is with glyphs that have the same class but different contours,
Right now the class kerning is optimized for storage, not for humans to look at. It ignores pairs that will never occur in real life (or so it believes).
More and more, I realize this is bugging some users and I may introduce directly “looking at the shapes” in the class kerning algorithm.
Morula Type wrote: 04 May 2022 especially when kerning size is set below 10Kb.
If your font includes Cyrillic then it’s likely to have a large glyph set (1000+ glyphs, I suppose?). May I ask why you are setting less than 10Kb? Is it about webfonts? If not then I’d strongly recommend to set it to 60kB as there is no benefit in reducing the file size for desktop fonts.
Morula Type wrote: 04 May 2022 T and de-cy
Тд has very low priority in Kern On’s list (as you can see if you open pair_frequencies.txt contained in the plug-in). According to me research, it is extremely unlikely to occur in real life. I just had a look at a few hundred MB of text from Wikipedia in Russian, Ukrainian and Belarusian each, and couldn’t find a single case.

Can you explain why you think Тд is relevant?
Morula Type wrote: 04 May 2022 but I think that very common pairs (like UC + LC) must be given higher priority
No, keep in mind that not all UC+LC pairs are very common.
Morula Type wrote: 04 May 2022 like colon, which results in hyphens and dashes getting too close or crashing into them.
Are you talking about emoji?

I don’t think hyphens are likely to come after colon but I may just throw a few more combinations of colon+hyphen and colon+dashes into the list. Some things are a tough call.
Morula Type wrote: 04 May 2022 Oh, also: why are braces and other important glyphs set to "no kerning" by default?
The default kerning types come from another internal list, plus some guesswork. If the font you have opened seems to be “nearly completely kerned”, and some glyphs do not have any kerning at all then KO thinks the user simply does not want them to be kerned at all. It seems you opened a font that had “nearly complete” kerning, including punctuation, but no kerning for the braces. As a result, they were set to “no kerning”. Maybe I should increase the threshold that makes KO think the font is completely kerned.
Morula Type
Posts: 8
Joined: 03 May 2022

Re: Class kerning reliability

Post by Morula Type »

Thanks for your reply!

[quote="Tim Ahrens" post_id=911 time=1651737514 user_id=2]
May I ask why you are setting less than 10Kb? Is it about webfonts?
[/quote]

Yes, I remember reading on this forum that you recommend something like 8Kb for webfonts. Is that correct?

[quote="Tim Ahrens" post_id=911 time=1651737514 user_id=2]
Can you explain why you think Тд is relevant?
[/quote]

It's not relevant, but it makes me doubt about how the other classes are set. I imagine typing random letters in a web tester and seeing a pair like Vg having wrong kerning while something like —Ф crashing while it could simply be left untouched: if I were a graphic designer with no knowledge of linguistics or type engineering, that would probably make me think the whole font is badly spaced, even though those pairs would never be used in real text.

[quote="Tim Ahrens" post_id=911 time=1651737514 user_id=2]
I don’t think hyphens are likely to come after colon but I may just throw a few more combinations of colon+hyphen and colon+dashes into the list. Some things are a tough call.
[/quote]

I don't think so either, and this is not the issue. The issue is a letter having the same class as, say, the colon and thus be kerned inward after a hyphen, even though it's a different shape. Example: -: (kern=-50) -Ф (kern=-50)
Actually, I see no use for many pairs that appear in the final table. Two examples I found just now: (zero.dnom + æ) and (endash + endash). Wouldn't it be better to leave these pairs out of the list? This happens when the size is >60 as well.
There are also some pairs that crash into each other inexplicably, I'm attaching some images of them.

The fact is that I can't possibly inspect 16k pairs, so I have to trust the algorythm completely, and these inconsistencies can't be allowed into the final product, even though they'll rarely, if ever, appear.

[quote="Tim Ahrens" post_id=911 time=1651737514 user_id=2]
If the font you have opened seems to be “nearly completely kerned”, and some glyphs do not have any kerning at all then KO thinks the user simply does not want them to be kerned at all.
[/quote]

Ok, I guess I can manage this with the overview control, turning those characters into standard kerning ones. Good to know!
Attachments
Screenshot 2022-05-06 at 05.11.20.png
Screenshot 2022-05-06 at 05.11.20.png (76.61 KiB) Viewed 11408 times
Screenshot 2022-05-06 at 05.15.56.png
Screenshot 2022-05-06 at 05.15.56.png (105.87 KiB) Viewed 11408 times
Screenshot 2022-05-06 at 05.17.05.png
Screenshot 2022-05-06 at 05.17.05.png (100.55 KiB) Viewed 11408 times
Morula Type
Posts: 8
Joined: 03 May 2022

Re: Class kerning reliability

Post by Morula Type »

Hi there, any news on why this happens or how to solve it?
Post Reply