Proofing Kern On results - How do you review thousands of pairs?

James Puckett

I decided to try Kern On with my latest typeface. After deleting all the small pairs (less than 5) and cleaning up some garbage (pairs for CALT glyphs) I still have over 7,500 pairs in each master. And the kern values are terrible for many pairs. Going through them one by one in Glyphs would probably take longer than just kerning the typeface in MetricsMachine. How are people dealing with this? Are people just crossing their fingers and hoping that Kern On did a good job? 

Igor Petrovic

In addition to your questions, does Kern On requires predefined kerning classes?

John Hudson

In addition to your questions, does Kern On requires predefined kerning classes?

No. I run it without kerning classes, and then do class compression after the fact.

And the kern values are terrible for many pairs. 

Define models for some of those pairs to adjust the output?

John Hudson

Another way to use Kern On is to do manual kerning for the core of your design, and then use that kerning as a model to extend the kerning into the edge cases.

John Hudson

[To date, I have only used Kern On for syllabic scripts where the number of potential pairs is more than can reasonably be kerned manually.]

Aaron Bell

Results out of KernOn are only as good as the inputs you give it. I've been using the TypeFacts kerning test (https://typefacts.com/artikel/kerningtest) to help define models (which provides a pretty solid starting point) and then do a general review of kerning sheets from there. I've found the results to be pretty good.

Simon Cozens

One of the reasons I gave up on my experiments with automated kerning is the problem of verification. Unless you trust the algorithm implicitly, you end up having to verify all the pairs that it generates (and also all the ones that it doesn't!); and if you're manually verifying every kern pair anyway, how much do you actually gain from an automated system?

Thomas Phinney

I kind of figure that one might gain that trust over time? If the algorithm is good enough.

Jasper de Waard

Aren't you always manually checking to see if your kerning is good? Whether that kerning is automated or not. I would assume that it's the stage before that, the bulk of the kerning work, that is sped up by a tool like Kern On. Furthermore, I have the feeling that a few silly mistakes tend to slip through the net when I kern manually, that may have never occurred when kerning was automated. Just to defend a plugin I have never used

Ray Larabie

Are there any reliable autokerning systems that don't require Apple hardware?

Jens Kutilek

I can’t comment on its reliability, but DTL KernMaster is available for Windows.

John Hudson

I used DTL KernMaster on a project a long time ago. It did a pretty good job, but it is less flexible than KO: you need to define a pair list, and there is no iterative input, only some values that you can adjust to trigger looser or tighter kerning.

The big problem I have found with previous auto-kerning is that even when it did a good job in terms of internal consistency of output, it didn’t kern anything like the way I would have kerned manually. So I either had to accept that or throw it out and kern manually. The iterative model aspect of KO is what I like, and why I think it is the best approach. Also, Tim is very responsive to issue reports.

John Hudson

BTW. Discovered in investigating a weird KO outcome with Tim that KO does not play well with quadratic outlines, so some distances were being incorrectly calculated. So if using KO on projects involving native TTF outline sources, you should run it in a separate .glyphs source with outlines converted to cubic béziers, then copy the kerning over to your main source.

Andrea T.

I started to use KO recently, and it works fine for me. I usually start using the interactive KO engine and then I prepared some tabs with the most common kerning pair in latin script (and cyrillic when is present) and I correct and refine the kerning directly.

Usually I ended up with having at least 100 models and some exceptions. After that I test the kerning on some sheets I made on indesign and web browser, refining every time going back and forth in the master file and in the test specimen. I have to be sure to exclude from the kerning engine a lot of glyphs and I tend to keep the kern table as small as possible (15kb to 25 kb). I also run a lots of scripts that helps me to check the result (kerncrasher, overkerned pairs, large pairs all of them from mekkablue library).

It is a long process and full of small mistakes. But at the end I will have a more than acceptable kern mostly extensive, saving a lot of time and my mental health.

At the end I accept some imperfections in my kern (at least in the less important pairs) it is the nature of automatic generated stuff, I always think that my eyes are much more reliable than a computer, but I'm not sure anymore if this is true or just my bias (I always thought computers are just fast and stupid).