Kern On—Semi Automated Kerning Plugin for Glyphs
James Puckett
Posts: 1,992
Tim Ahrens of Font Remix Tools fame has just released Kern On. Kern On is a tool that allows designers to set model pairs for how a font should be kerned and used them to generate kerning for an entire font. I think that it’s going to save me lots of time in the future.
9
Comments
-
Sounds promising. I hope there will be a Windows version (for the sake of diversity).2
-
As it is a glyphs plug-in, I doubt it. Personally, this is a bigger enticement to switch OS than any mac-specific type apps I've seen yet. Is there anything remotely similar for FontLab?
0 -
@Matthijs Herzberg It's just that so many people in this world would have to rob a fancy restaurant to be able to switch OS... (As for myself, even though I could easily switch, I would feel dirty. Well, dirtier.)0
-
I’m open to make it available in other environments/font editors but it has to be economically feasible.
6 -
I’m open to make it available in other environments/font editors but it has to be economically feasible.May I humbly suggest that such is a two-way street. Personally, I find kerning to be rather tedious and would be willing to pay handsomely for a tool which reliably cuts the tedium down.
3 -
The tool seems to be very interesting at least from the website demos, great job Tim!
However, I’m curious whether setting up the models, “debating” with the computer and then making sure it has kerned everything correctly and/or correcting the result could be more time consuming than old-fashionly running through a carefully made kerning list manually?0 -
Wondering if anyone has tried to implement this and any feedback so far? I'm close to the kerning phase on a current family, so I'm curious (I think the trial ends soon... Oct. 31).0
-
-
Me too.would be willing to pay handsomely
1 -
Adam Ladd said:Wondering if anyone has tried to implement this and any feedback so far? I'm close to the kerning phase on a current family, so I'm curious (I think the trial ends soon... Oct. 31).personally I will never go back to kerning another way. there have been so many tools to promise what kern-on can do, and it is the first to truly deliver, IMO.Alex Visi said:I’m curious whether setting up the models, “debating” with the computer and then making sure it has kerned everything correctly and/or correcting the result could be more time consuming than old-fashionly running through a carefully made kerning list manually?my experience has been that the "debating" with kern-on mostly improves my spacing! it's great. if it suggests something that seems off, more often than not, I find that my sidebearings are the real problem even if only by a couple of units.RE: carefully made kerning lists - what kern-on would primarily offer you is that you could trim down the list considerably, most likely. you still need to train kern-on with model pairs, and examples of pairs that should not be kerned.more generally though, I would say kern-on is a different workflow for kerning, and one that I prefer. I think it de-risks the reasons why you normally kern at the very end, and instead allows you start kerning toward the end. this may seem subtle, but working with a huge glyphset, adding some extra glyphs and stylistic sets, occasionally re-thinking some spacing decisions, etc — all that stuff that comes up in the last mile of a font, this de-risks it. if you've already kerned the font with kern on, you can make changes and just hit the "run" button again and there's no harm. of course, if you start kerning too early, you will run into spacing issues.in any case, I dont mean to sound like an advertisement. it saves me a ton of time on this font I'm working on with 1400 or so glyphs across many masters, and the results are good, so I'm a fan.12
-
How long (approximately) does it take to kern a font with Kern-On?
Let's say it a serif with MyFonts minimum set LINK.0 -
Remarkably little time. I recently kerned an Ethiopic font (using a test build of KO, the release version doesn’t support Ethiopic yet), and I was able to define about 100 model pairs in about half an hour, then spend another half hour reviewing results in test strings, before hitting the KO button to apply kerning to the whole font. That last step took several minutes to complete, because the Ethiopic kerning is based on an all-to-all syllable kerning that produced about 150,000 kern pairs.5
-
Hi Tim... some time ago I started developing a tool to asist and improve the kerning process by letting you know what have you kerned and what you have not kerned.. and at the same time it lets you check the kerning result in context.. by showing you words that use kerning and words that dont use kerning at all.
This tool wont kern for you.. it will generate reports and customized blocks of text so you can evaluate your own kerning.
It was a bit complicated to use, since various steps where needed.. 1) stack the kerning from your font using a macro 2) uploading the kerning file to the server 3) editing the source code etc.. and you need to do it all again in your next kerning round iteraction.
A pain in the ass.. but the resulting pages where so good in helping you realice the "global" efect of kerning individuals pairs that all the trouble was tolerated.
The main idea is that when you are kerning you tend to focus to much on individual pairs.. and most of the times the pairs dont work well with the spacing cadence of the typeface.. and this tool lets you make shure that your kerned pairs are "invisible" in the general context of the typeface spacing. Basically it lets you make shure that you are not "overkerning" so your kerned pairs wont look like aliens when they are in the context of not kerned pairs (just spaced).
Some stonecutter master once told their student that you can only set good spacing when you have a least 3 letters.. since the spacing from 1 to 2 should be similar to the space from 2 to 3. That means for us that the letter pair that uses kerning need to play nice with the next letter. Since we are kerning words, not just pairs.
Too many times in to many typefaces the kerned pairs ends up looking like a bad cluster inside a longer word.
This tool let you preview the results and the quality of your spacing and kerning decisions as you go. It makes it super easy to spot and correct problems.
It shifts the focus from the pairs and lets you see how the whole thing.
You get a birds eye view.
The tool source code is on githup.. you may not be able to run it.. but please have a look at the screenshots included in the description.. you will see the tool output and you will quickly understand the idea.
If there is anything you find usefull in you tool, please fell free to copy the ideas.
https://github.com/impallari/Contextual-Kerning-Tool
Some of the screenshots of the tool in use:
https://github.com/impallari/Contextual-Kerning-Tool/blob/master/images/sample01-lowercase.png
https://github.com/impallari/Contextual-Kerning-Tool/blob/master/images/sample02-uppercase.png
https://github.com/impallari/Contextual-Kerning-Tool/blob/master/images/sample03-capitalized.png
And just for fun.. it lets you compare what pairs have you kerned against another typeface.
Good for learning spacing strategies.. but also good for comparing diferent versions of the same font.. for example when you update your own fonts
https://github.com/impallari/Contextual-Kerning-Tool/blob/master/images/sample04-compare.png
I will love to see this tool developed for glyphsapp! are you interested?
It can work as a complement to fine-tune, test, review and improve the results of what the user have done when they use of your awesome kerning tool. Its the perfect complement!2 -
I had the same thoughts when setting up my model pairs in Kern On. Usually I get words, sometimes, usually with punctuation, I just get a pair. e? isn’t enough information on its own. When I’m doing punctuation I miss my MetricsMachine contexts.PabloImpallari said:
The main idea is that when you are kerning you tend to focus to much on individual pairs.. and most of the times the pairs dont work well with the spacing cadence of the typeface.. and this tool lets you make shure that your kerned pairs are "invisible" in the general context of the typeface spacing. Basically it lets you make shure that you are not "overkerning" so your kerned pairs wont look like aliens when they are in the context of not kerned pairs (just spaced).
Some stonecutter master once told their student that you can only set good spacing when you have a least 3 letters.. since the spacing from 1 to 2 should be similar to the space from 2 to 3. That means for us that the letter pair that uses kerning need to play nice with the next letter. Since we are kerning words, not just pairs.
To many times in to many typefaces the kerned pairs ends up looking like a bad cluster inside a longer word.0 -
How do you proof that? Did you have someone code you a tool that can generate a massive PDF? And if so, how many days did it take to review the results?John Hudson said:That last step took several minutes to complete, because the Ethiopic kerning is based on an all-to-all syllable kerning that produced about 150,000 kern pairs.0 -
That 150,000 kern pairs is the raw output from KO. The first thing I do is to reduce that amount in various ways. The kerning includes a lot of small value pairs that I simply delete, e.g. anything 5 units or less. I then round all the values to multiples of 5, which will reduce the number of exception pairs when I compress to class kerning. Then I compress to class kerning, which in this case brought the kerning down to about 70,000 pairs.
First review is testing pages of random text, looking for patterns of things that might be wrong. The nice thing about using a tool like KO is that any errors in the kerning are going to be systemic, which means if I spot an error in one pair I can anticipate and check where else it might occur. I reported an issue to Tim a couple of days ago regarding a particular Ethiopic shape that KO was consistently kerning too tightly. It makes more sense to report kerning errors as KO bugs than to fix myself: the ultimate goal is to be able to trust KO.
Second review is stepping through the kern pairs in context in FL7’s kerning window. This is fairly rapid, even for a huge kern set, because all I am looking for is significant changes in spatial frequency in the middle of the context.3 -
Bumping this again a year later... any new updates or experiences with Kern On continued use for those who have given it a shot or adopted into their workflow?0
-
I continue to use it for syllabic scripts, where the processing power saves a huge amount of time and produces a large set of visual kerning values. Most recently, we worked with Tim and with Kevin King at Typotheque to get support for Canadian Aboriginal Syllabics added to KO. In that case, we were able to define a couple of subsets by isolating those syllabic characters used only for the Carrier language.
So far, I have not used KO for any European scripts, but might experiment with it in the coming weeks to see if it is helpful in extending existing kerning in my Brill fonts to new Cyrillic and Latin additions. I suspect I may need to engage with Tim again to get these supported, as they involve obscure historic characters that won’t have been covered in his general corpora analysis.3 -
I hear it is popular in the professional industry and used widely.
3 -
I've now worked on a couple of latin-cyrillic projects with it (with some pretty old cyrillic forms, but probably not the early cyrillic that I assume john is talking about) and haven't had issues.. the main thing I find myself wanting is support for contextual kerning - being able to kern e.g. two characters on either side of the space. glyphs 3 does support contextual kerning and there's been some discussion on the KO forum but it was a while ago at this point..3
-
KernOn is great! It took me a bit of time to figure it out, but then it replaced weeks of kerning with a couple of days. Although there are some tiny changes I would like to see in its functionality, I'm never going back to manual kerning. Just a bit friendlier UI and some tool tips and hints and it will be perfect.2
-
Working with it with a 3 master (weights) family right now. One of the big hurdles has been the kerning exceptions that are created (i.e. unlocked pairs, seen via the lock/unlock icons).
Some seem to be rational based on potential collisions (or at least being tighter visually) with diacritic glyphs, but some I don't want to have a different kern value. And these are hard to find without toggling through every diacritic next to another glyph.
Example: AYÃ ... AY vs YÃ has a value difference of 40 units. While AYÄ was ok.
(I have pre-set my kerning groups to try to eliminate the inconsistency, and also tested it where Kern On generates the groups.)
The other hurdle that is challenging to find and fix are cases where values of a three letter grouping are asymmetrical.
Example: V-V ... the values between the '-' on both sides are -2 to -30 difference.
The overall results and texture are good and require understandable review time, and I think I have to learn to trust some of the unlocked exceptions that are created (not touch them), but cases like the above that seem like hidden errors are hard to find and address without looking at every single pair and diacritics that are supposed to be grouped.
I found this article, but I'm curious if others have run into this. Trying to understand expectations. https://kern-on.com/forum/viewtopic.php?t=3998&hilit=unlocked1 -
I have noticed this as well. I don't know if I've had it for V-V specifically but it does happen with relatively common pairs. I find myself taking an auto kerned pair, and dragging the slider all the way to the left to make that pair match another existing model that I would prefer it be the same as, like your AYÃ example. for me, pairs like AYÄ can be off as well. I will have AY defined as a model in this case1
-
Example: AYÃ ... AY vs YÃ has a value difference of 40 units. While AYÄ was ok.
The standard practice should always be to set a model for any kerning pair you are not satisfied with, rather than changing things after the kerning is finalized.If I understand you correctly, YÃ is too loose compared to AY? Then the question is: Is AY too tight (and YÃ is correct), or is YÃ too loose (and AY is correct)? If YÃ is too loose then this is a problem in itself (and the symmetry check is only how you found it). You should try setting YÃ as a model with the desired kerning value.Example: V-V ... the values between the '-' on both sides are -2 to -30 difference.
This is strange. Would you mind sending me the file? Without seeing it, my suspicion is that the special spacing is not symmetrical, which would cause asymmetrical kerning, of course.
1 -
Thanks for your reply @TimAhrens and the further advice.
You're correct...
AY is correct and the preferred kerning (which I think was defined by the model pair YA in the beginning). YA is also correct. But YÃ is too loose in this case.
ÃY is also basically correct in some weights, but not all (although both locks became unlocked and the value is different by 1 unit). And as Jeremy noted, some other diacritics in this pairing example jump around some (though not all).
Yes, I'll email you the file. Appreciate it.
This has been a work in progress and getting used to things and what to watch for. I'm excited about the tool and potential with some of the overall results so far.
0 -
I am guessing / wondering if this is a case where kern on is too agnostic from seeing masses of dark and light rather than letters (which in many other cases is a benefit, as this helps it work across many styles and scripts). in, e.g. YÃ there is a larger mass on the right than in YA, and it adjusts for that. which is a reasonable thing for a kerning machine to do. but I think the result is somewhat unnatural because that’s not how we write. as long as the diacritic mark is not wider than the base letter (e.g. a sans ÏÏ), I expect the base letter to take on greater importance in determining the kerning value than the composite glyph as a whole. it might not be perfectly symmetrical, and there are typefaces where pairs like this will be looser, as well as type designers who would prefer something different than me, but the issue is that if I do try to teach kern on to be more symmetric by making YÃ a model that has roughly that same value as AY, it does not learn that this is my opinion when it comes to another pair like YÄ. it’s hard to know what the threshold of pairs is where it will start to understand what I want it to do in this regard, which means I end up with more kerning models than I would like
1 -
Let’s not pretend Kern On always kerns AY and YÃ differently, without even having seen the case in question. This is not a very common case, I believe.I do have the file now and it is an intriguing case, I must say.Of course, the presence of additional black makes it – in principle – reasonable and correct to give YÃ a little less negative kerning than AY, especially if the tilde is placed rather low. So, this is not an obvious, clear malfunction of the tool.Still, if YÃ is unusually and noticeably looser then we need to find a way to fix it. As always, setting additional models is the solution, and this works. The font in question (which I am not allowed to show) still has a moderate number of models (under 70) and some of the autokerning is not very tightly defined (the AY has many tickmarks, for example). So, this is not a case of ending up with an unreasonable number of models only to fix all the cases when the autokerning is not as we wish, and let’s hope it won’t become like this.It is always an interplay of several models, of course. In Adam’s case, it is possible to sort things out by setting and adjusting a couple of models.What’s more, I started implementing a way of de-emphasizing the accents on the capitals (i.e. anything above the cap height, for all capital letters). The same mechanism of de-emphasizing anything below the baseline and above the x-height, as much as necessary, already exists for the lowercase letters. So, this is a tried-and-tested mechanism that I simply had to apply to the UC letters in the same fashion. Seems helpful.One other thing I noticed is that in AYÃ, our perception seems to be influenced by the symmetry it encounters (thinking of gestalt psychology). This impression is so strong that we expect the symmetry principle to override the fact that the presence of the tilde justifies, or even requires, a somewhat looser spacing. What happens if we compare EHYÃLO and EHYALO? To me, this doesn’t look quite as wrong as AYÃ but we still want to fix things, of course.
3 -
Regarding the asymmetry in V−V:This only occurs after finalization, with manual kerning groups. While KO is running, you can see that V−V is completely un-kerned because the minus is set to “No kerning”. Is this intentional? I just had a discussion with someone who consciously used this as a hack.This is happening:• “No kerning” does not guarantee that the glyph will be un-kerned in the end. Rather, it is removed from the system, which means the associated pairs are considered to be irrelevant. With “Re-generate kerning groups” checked, it does end up reliably without any kerning. With manually set kerning groups, funny things can happen.• If the minus is set to “No kerning” but it is in the same (manual) group as a kerned glyph then this is a contradiction, of course. Don’t be surprised if strange things happen if you give paradoxical instructions. In the best case it can serve as a hack but as always, hacks are unreliable so I’d advise against them. If you use manual groups the aim is obviously to get more predictable results, not less predictable ones.In other words, if you use manual groups, “No kerning” tells Kern On “I don’t care what the kerning of this glyph is,” rather than “Please ensure that this glyph is un-kerned,” and certainly not “Please ensure that this glyph has the same kerning as another”.I will implement something to prohibit this hack and the resulting unpredictable behaviour in the first place. Probably, Kern On will remove any kerning groups for glyphs with “No kerning”. After all, this is the statement made by the user.Hope this helps for now!1
-
it was not my intention to imply this, if I did - you are right of course, it isn’t always different. it's just one of the pairs where it can happen, so I figured I'd continue using adam's examples for simplicityTimAhrens said:Let’s not pretend Kern On always kerns AY and YÃ differently, without even having seen the case in question. This is not a very common case, I believe.given how well this works for lowercase (I wasn't aware this was happening but it seems obvious now), I suspect this would be a great improvementWhat’s more, I started implementing a way of de-emphasizing the accents on the capitals (i.e. anything above the cap height, for all capital letters). The same mechanism of de-emphasizing anything below the baseline and above the x-height, as much as necessary, already exists for the lowercase letters. So, this is a tried-and-tested mechanism that I simply had to apply to the UC letters in the same fashion. Seems helpful.
this is why I think that, along your idea above for de-emphasizing forms above the cap height, it's still important to look for defined pairs that apply logic to glyphs containing those de-emphasized forms. this way, if YÃ is kerned in whatever way makes the most sense to the individual designer, if someone does for example want EHYÃLO to be considerably wider than EHYALO, kern on would think to itself "I see what jeremy is intending to do with forms above the capital, and am going to apply the YÃ logic to YÄ as well." so deemphasized but still considered amongst alike pairs. maybe the way you're thinking about it, this isn't actually a risk, and I'm reading too far into the word "de-emphasizing" though!One other thing I noticed is that in AYÃ, our perception seems to be influenced by the symmetry it encounters (thinking of gestalt psychology). This impression is so strong that we expect the symmetry principle to override the fact that the presence of the tilde justifies, or even requires, a somewhat looser spacing. What happens if we compare EHYÃLO and EHYALO? To me, this doesn’t look quite as wrong as AYÃ but we still want to fix things, of course.0 -
it's just one of the pairs where it can happen, so I figured I'd continue using adam's examples for simplicity
Yes, in a way, AYÃ is something of a litmus test. Of all caps-with-diacritics pairs, it should be the one that most clearly demonstrates the issue because the tilde tends to be wide and positioned low (at least on the left).if someone does for example want EHYÃLO to be considerably wider than EHYALO, kern on would think to itself "I see what jeremy is intending to do with forms above the capital, and am going to apply the YÃ logic to YÄ as well."
Yes, this is exactly how Kern On is meant to work, in every respect: The designer’s preferences are deduced from the models. For lowercase, the de-emphasis of the zone outside the x-height is a parameter between 0 (no de-emphasis) and 1 (significant de-emphasis). The necessary value is derived from the models. Now I need to decide whether to have to separate parameters for the de-emphasis in UC and LC, whether it is necessary to have this flexibility, or whether they are conceptually linked and giving the algorithm too much to fiddle around with is counterproductive if we consistency across the font is the goal. Although Kern On does not use any sort of AI or machine learning, this question is related to the problem of overfitting in that field.There are other such parameters which the users are not aware of, some of which are difficult to describe as they are abstract mathematical concepts and some are related to the inner workings of the engine, which is, after all, secret.2
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 798 Font Technology
- 1K Technique and Theory
- 617 Type Business
- 444 Type Design Critiques
- 541 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 498 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports