How to avoid overkerns?

[Michal Chrastina]

Hey, thanks for this great tool, it just keeps getting better and better.
I have just one small issue. When I generate kerning with KernOn, and then check the result with Mekkablue script "New Tab with Overkerned Pairs", it prints a lot of pairs. (my font has 2036 glyphs). When I fix pairs in KO, KO does not like it as it contradicts other pairs. I guess the solution is to set all overkerned pairs as Independent pairs, but that does not guarantee that KO won't generate new overkerns. So for now I just fix overkerns with the Mekkablue script.

My question is, is there a better way to avoid overkerns?

[Tim Ahrens]

Just tried this script myself.

One question is, where does the default 40% come from? What is the reasoning? Kern On limits the negative autokerning to 50% of the smaller advance width.

If I set 50%, the script wrongly reports pairs. In other words, the output of the script is incorrect even according to its own rules. Just look at the advance widths of the glyphs and the kerning value and you will see that the script shows pairs that do not fulfil what it was supposed to show.

In other words, trust Kern On. Don’t trust this script. There is no need to “fix” the pairs reported by the script as there is no reason to.

[Tim Ahrens]

Here is an example for reference. As you can see, the kerning value (-138) is exactly -50% of the advance width of quoteright (276). Even though, the script shows this pair if I set the threshold to 55%.

[Michal Chrastina]

>One question is, where does the default 40% come from?
I don't know where the default of 40% comes from. I always set it to 50%.

>If I set 50%, the script wrongly reports pairs.
Oh that is true. Never noticed that. It makes minor false positives for me too. Thanks for pointing this out.

>In other words, trust Kern On.
I would love to, but KO keeps overkerning

[Tim Ahrens]

> I would love to, but KO keeps overkerning

Thanks for pointing this out. I found out what is happening. This happens because Kern On usually has to omit exceptions in order not to exceed the given kB size. This means that, for rare pairs, we have to accept that the final kerning value deviates from the ideal. The deviation could be that the class kerning value is too large or too small. The whole mechanism of fitting “as much/important kerning as possible” into the given kB is lossy, which we always knew, and which is unavoidable.

In this case, the class kerning value is too small (large negative), which makes the pair violate the rule that kerning should not be more negative than half the smaller advance width.

The question is, is this deviation from the ideal significantly worse than other deviations, because it violates a clear-cut rule? Or, is it just easier to detect?

[Tim Ahrens]

Update:

• It turned out that the script “New Tab with Overkerned Pairs” did not consider exceptions. I implemented that, and it is updated in the live version now. So, we should not get false positives from the script any more.
• I also slightly tweaked the algorithm in Kern On so as to avoid generating overkerned pairs due to missing exceptions. It will be in the next Kern On update. You may still find a small handful of pairs even with the updated script, and even if you set the threshold to 50% as per Kern On’s reasoning.
• Whether 50% or 40% is a more sensible approach is debatable. Of course, choosing a lower (stricter) value will be even safer against overly tight spacing that may occur in the rare cases when we have two strongly kerned pairs following each other. On the other hand, reducing the (negative) kerning even further will make it even more “wrong” (different from the ideal) in the general case and I don’t think it is sensible to sacrifice good kerning in the general case in order to slightly improve some rare cases.
• Keep in mind that the output of the script “New Tab with Overkerned Pairs” is not to be considered totally obvious, catastrophic errors that can easily be fixed. Consider them warnings. If you decide to reduce the kerning for the pairs the script considers “overkerned”, keep in mind that this deteriorates the kerning for the majority of cases that will occur in real life.

[Tim Ahrens]

Btw, the only perfect solution to handle the challenges described above is to use kerning triples. Implementing this in Kern On is fairly high on my to-do list, and Glyphs will also soon be more powerful at handling triples, I heard. ;-)

[Michal Chrastina]

Thank you for an extensive reply. Now I understand what is going on.

>In this case, the class kerning value is too small (large negative), which makes the pair violate the rule that kerning should not be more negative than half the smaller advance width.
<I still do not understand why Kern On assigns any kerning to pairs that violate its own rules. In my opinion, it is better to have no kerning than wrong kerning, but I might be wrong.

>It turned out that the script “New Tab with Overkerned Pairs” did not consider exceptions. I implemented that, and it is updated in the live version now. So, we should not get false positives from the script any more.
<Wow, thank you!

>Btw, the only perfect solution to handle the challenges described above is to use kerning triples. Implementing this in Kern On is fairly high on my to-do list, and Glyphs will also soon be more powerful at handling triples, I heard. ;-)
<Oh, triplets would be perfect to have in Kern On.

[Michal Chrastina]

><I still do not understand why Kern On assigns any kerning to pairs that violate its own rules. In my opinion, it is better to have no kerning than wrong kerning, but I might be wrong.
<Oh, I think I understand now. I suspect the deviations from ideal happens in class to class kerning, this would require exceptions, therefore it would not fit in provided kB limit.

[Tim Ahrens]

Yes, that’s exactly the problem.

[DanielNiz]

I've been struggling with overkerns in my design work lately, and I was wondering if anyone has any tips or tricks to avoid them. I find that sometimes when I'm adjusting the kerning between letters, I can go too far and end up with overkerns that make the text look awkward and unbalanced. Do you have any techniques for keeping kerning in check and ensuring that your text remains visually appealing? I would love to hear some insights from fellow designers on how to tackle this common issue. Thank you in advance for your input!

[Tim Ahrens]

Daniel, what exactly does “overkern” mean as you use it? The term does not have a clear definition, and it is not widely used.

The script referred to at the beginning of this discussion calls “overkerned” any pair that has a strongly negative kerning compared to the smaller advance width of the two glyphs. It is a fairly objective and somewhat technical consideration. It’s a very specific problem that arises when we consider glyph triples, and it is unrelated to visual judgment. This is how we have been using the term “overkerned” in this discussion so far.

It appears when you say “overkerns” this means “pairs that are too tightly kerned for my (visual) taste”? That’s an entirely different issue from what we have discussed on this page so far. If any of the resulting autokerning is too tight for your taste, just set the relevant pairs as models, with less tight kerning, and Kern On should quickly follow suit and generate looser autokerning, in particular for those pairs that have shapes that are similar to your models.

[Tim Ahrens]

Oh dear, I just found out that “DanielNiz” is in fact a spam account. Seems like LLMs are getting good enough to fool me (and the spam filter, which usually works quite well). In future, I’ll face the challenge of trying not to waste my time with stupid LLM-generated posts but also not to insult real users by considering their posts to be stupid and LLM-generated.

[brianbrubaker]

> Oh dear, I just found out that “DanielNiz” is in fact a spam account.

Geeze! Why would this even be a thing on a forum like this if the bot is engaging on the topic at hand (as opposed to posting spam hyperlinks? Cui bono?

[Tim Ahrens]

Some spam filters are set to allow all posts from users that already have at least one approved post (I just saw that setting in my own filter but it is not active). That explains the strategy: first, one innocent post, followed by spam posts.