Too many Independent Pairs, Missing Kerning

[mckc]

First of all let me say that this is a phenomenal achievement. It's a super smart approach, a great foundation to simplify the kerning process and in some cases make to it even more precise.
I am brand new to KO, so maybe some of my questions stem from a lack of technical understanding. But as of now I am torn between taking it is a tool to actually fully kern my typefaces and, unfortunately, not using it.

I feel like KO tends to overkern some pairs. A lot of pairs don't even need kerning at all, especially in the lower case letters. When I set them to zero, they become "Independent" Pairs, and I end up with a lot of those "exceptions" where the process becomes more like the traditional, time-consuming kerning process. In the picture you can see that the "en" clearly doesn't need any kerning. Since KO doesn't allow me to take out the Kerning I end up with this. In the picture with the "lelel" you can see what KO's autokerning.
Maybe that's me being a traditionalist, thinking you should have as little kerning as possible, though. This is just one example of countless others. Maybe there should be a function like "Force to be a Model", where you tell KO that you know better and it applies the values to the other pairs from that Kerning Group. What I got from working with KO a few hours is that you should have as least Independent Pairs as possible to get a decent result. But too many times I just cannot accept KO's suggestions.

Another problem that is that no matter how meticulously I set up my Models every time I run my exported file through my Kerning Strings some things are odd, or even missing. A lot of times there are pairs in one string that have kerning (often very good amounts) and other pairs in the same string don't have any. Why does the "iŁ" have positive Kerning but the "nŁ" doesn't. Other examples are "Bï" (kerned), "Zï" (unkerned), "ďt" (kerned), ďf (unkerned), "T₃" (kerned), "T₄" (unkerned). Those exceptions are so random that i don't understand where they come from.

Those are the two main things that, unfortunately, keep my from being overly excited. I hope that it is just my lack of skill and understanding and not the KO's fault.

[Manuel]

I had pretty much the exact same issues as you are showing with the e.

[Tim: Oops, I accidentally edited this post and it is not possible to restore the original. Sorry about that!]

[Tim Ahrens]

Hi mckc:

overkern

Let’s try to avoid this expression; it does not have any clearly defined meaning (and it is not commonly used afaik). In Rainer’s script it has a very specific meaning (see discussion here), it seems you are using it with a different meaning (and, funnily, that spam bot with yet another meaning).

When I set them to zero, they become "Independent" Pairs

Well, they don’t just become independent pairs – Kern On explains that it had to do so because it contradicted another pair. It’s worth investigating and fixing that contradiction, rather than keeping it as independent pair.

Since KO doesn't allow me to take out the Kerning I end up with this. In the picture with the "lelel" you can see what KO's autokerning.

Not sure what you are trying to explain. The crucial question is, why did Kern On remove the model? What was the contradiction?

Maybe that's me being a traditionalist, thinking you should have as little kerning as possible, though.

I totally agree. You should try to set up the spacing and models so that the result is as little kerning as possible.

Maybe there should be a function like "Force to be a Model", where you tell KO that you know better

This is practically what you do by clicking “Try again.” Kern On will understand that you really want this particular pair, and keep it.

It will have to remove another pair instead. Again, my advice is to investigate the contradiction and fix it.

and it applies the values to the other pairs from that Kerning Group

While Kern On is running, it does not know about kerning groups; this information does not even exist in the engine. It only thinks in terms of glyph-glyph pairs. Kerning groups are automatically generated, or retained, as you finalize the kerning.

you should have as least Independent Pairs as possible to get a decent result

Yes, absolutely. Maybe I should emphasize this more. Independent pairs are a “parking” for deactivated models. The only reason why models, when they have to be removed, are not switched to auto pairs is that they would lose their previous kerning value. By switching them to independent pairs this information is retained.

Why does the "iŁ" have positive Kerning but the "nŁ" doesn't.

Neither of them are in the internal list of pairs. In your case, class kerning applies to iŁ because the i is in a kerning group with another glyph that requires kerning against Ł. For nŁ, this is not the case.

The class kerning generation is a lossy compression. Like any lossy compression, it can lead to artifacts and this is no problem if these artifacts are invisible in real life. (A possible counter question would be, Why do you care about the kerning value of iŁ and nŁ?)

Other examples are "Bï" (kerned), "Zï" (unkerned), "ďt" (kerned), ďf (unkerned), "T₃" (kerned), "T₄" (unkerned).

Bï is a rare combination but it occurs in some words in Albanian, Occitan and Sango. It also occurs in the French Wikipedia several times.

Zï does not appear to be used in real life. This is why it is not included in the list of pairs.

Similarly for the other pairs. I don’t have the time to trace the origins of all these combinations but they are based on very extensive text crunching and post-processing (there is about 3 months of full-time work in the list of pairs). It is not set in stone, though. If you think T₄ should be kerned or T₃ should not be kerned then please explain and we can discuss (are you familiar with chemistry?).

[Tim Ahrens]

Manuel, sorry, here is the reply to what is left of your message:

What exactly was the problem? Did Kern On remove a model that contained the e? Which was the other model it was conflicting with?

It’s difficult to say what went wrong without seeing the file.