Kern On

In such a case, setting user-set autopairs is the way to go.

It is very strange that the pairs are not generated (or retained) during finalization, though, even with 0kB limit. Would you mind sending the me the file?

Thank you for the files. The pairs list contained in Kern On is based on extensive processing of real-world data, plus some common sense: some pairs are removed as a tidy-up, and some pairs are generated, when the list is created. The superior zeroes are generally not included after letters because ...

Thanks for reminding me of this. I updated the pairs list today, using the information on the usage of currency symbols from the Unicode CLDR. Plus, a few other updates and fixes (Glyphs likes to make changes that break add-ons, as you may know). The updated currency pairs will be in the next Kern O...

You could use this script in the macro panel: glyphNames = 'zeroinferior oneinferior twoinferior threeinferior fourinferior fiveinferior sixinferior seveninferior eightinferior nineinferior zerosuperior onesuperior twosuperior threesuperior foursuperior fivesuperior sixsuperior sevensuperior eightsu...

You can't just copy the models without setting values, or rather, if you do, Kern On will (rightfully) complain that you have lots of contradicting pairs. ... unless they are autokerned. Then you can switch them to models and there shouldn’t be any complaints (oops, this sometimes happens anyway, w...

Regardless of what is correct according to principals, people will use it both ways. I personally have seen euro used before and after numbers, I have even seen it used between numerals as a decimal such as 5€30 This is why currently, Kern On autokerns pairs for all currency symbols before and afte...

Kern On does support Vietnamese. If you find that certain letter combinations are missing then please let me know and we can have a closer look.

Thanks, I’ll think about it.

However, Kern On is not supposed to be a tool where you step through many pairs very quickly. It’s the opposite: use few pairs, but set them very carefully. I never felt the need for keyboard shortcuts, to be honest.

Uppercase letters to superiors are kerned.

There must ba specific reason why they aren’t kerned in your font. Feel free to send me the .glyphs file, then I can have a closer look.

Setting one side to “No kerning” is a smart idea, and it will work. Otherwise, enumerate all superior combinations and add them as independent pairs (userData key "KernOnIndependentPairs"). Yes, that’s another possibility. Just for clarification: set them as independent pairs with value ze...

If numbers to currencies are not kerned in your case then there must be a specific reason. Maybe your numbers or currency symbols are tabular? Kern On does not kern tabular glyphs. Or, they may be set to “No kerning”. It’s a tricky question which currency symbols should be kerned against figures bef...

Thanks for the notice! It’s fixed now.

I wrote something about Looking vs Thinking here: https://kern-on.com/manual/#q-looking-thinking Thinking that in an italic or slanted font, [H] is to be considered symmetrical, may be a case of Thinking gone wrong (i.e. an error in reasoning). My advice would be: Trust your Looking Trust Kern On (i...

This seems to be essentially the same effect:
https://kern-on.com/manual/#q-slanted-italic

Hope this helps!

What Sebastian said.

Are the pairs being auto-kerned, or is Kern On not correctly applying the calt feature? (Which may happen in complicated setups, in this case please send me the file if possible.)

Have you tried the “Clean up” functionality provided by Glyphs?

: Screenshot 2025-08-08 at 14.16.31.png (199.75 KiB) Viewed 10729 times

Looks like Kern On originally wrote the kerning and kerning classes (kerning groups as they are called in Glyphs). I’d assume something got jumbled after that. Without seeing the file, or knowing about the process this font went through, it is difficult to tell.

> But why does the single-to-single pair set not include relevant diacritic letters in the font, such as ĆĈČĊÇ Do you mean, it is missing relevant pairs? If so then please let me know, we can check and discuss, and I can add the missing relevant pairs. > If these were included, then I could use othe...

This is strange. Would you mind sending me the file?

This section in the manual probably answers the question: https://kern-on.com/manual/#how-kerning-is-stored In short, class-glyph and glyph-class kerning does not exist in TTF or OTF. If Kern On generated it then we’d usually have unnecessary glyph-glyph pairs in the final fonts. Class-glyph and gly...

I can see that rules could be useful in some cases but they are not implemented yet. To suppress kerning, you can use “No kerning” for glyph sides if that is applicable, or zero-value independent pairs but this is feasible only if there aren’t too many combinations. In the same sense, you can also u...

This is strange. ᒥᓗ is in the list of pairs that are to be kerned. One explanation would be that any of the glyph sides has “No kerning” specified by accident. Maybe this has happened?

This is a bit difficult to comment on without having the file. Keep in mind, though that the basic idea is always to set a pair as an additional model if you are not happy with the autokerning. Hope this helps!

You are right, something like “add missing user‑set auto pairs” would be useful.

Or, when text is in a tab, a function to “extract” (i.e. open in a new tab) only the missing pairs, like “Show ignored pairs”. I’ll see what works best.

If the slected pairs are already user-set autopairs (or the selection is mixed) then clicking “Auto” un-sets them. Just click again and they should all be switched to user-set autopairs.

You can write a small Python script that generates the pairs as text (one pair per line or with space character in between), then paste the text in an edit tab, select all, and activate “Auto”. Would that work? Alternatively, you can write them directly into GSFontMaster.userData (https://docu.glyph...

In case someone stumbles across a similar problem:

The problem was an #ifdef without a closing #endif in one of the features. As a result, Glyphs skips all code, i.e. all following features, including the kern feature it has auto-generated. So, this was not related to Kern On.

This seems like a strange problem. Would you mind sending me the .glyphs file? Then I can have a closer look.

Saying that the features are “pretty buggy” is not particularly helpful. If you experience any specific problems then please send me the file, with a description, and I can have a closer look, and fix things.

Kern On contains a built-in list of pairs that are autokerned by default. See https://kern-on.com/manual/#which-pairs-are-kerned . At the moment, before the √, there is only ()+−/± and various hyphens. I assumed other combinations are typographically not relevant but I’m open to discussion. The othe...

Sorry, this is a bug I also discovered a couple of days ago. In version 1.36, I tried really hard to avoid what some users consider “unnecessary” kerning pairs, and as a result, even model pairs would be written imprecisely in some cases. I just published an update, which should fix the problem.

Thank you for sending the file. What happened is that the A has special spacing (superiors) on the right side. I assume this is not intentional? I am wondering how this happened. When you set special spacing for a letter you will get a little warning dialog so as to ensure you do not do this uninten...

I doubt we will get a very quick solution within a few days.

Maybe you can send me the file with the original example of A and J? Then I can better understand what is really happening, and maybe I can implement a quick, hard-coded tweak for you.

To be honest, not all of these were direct reactions to this thread. Persistent autokerning is something I wanted to implement for a long time. I was going to write, the main crux seems to be irrational users who like things pretty under the hood... but, things a a little more complex, once again. S...

Thanks for your detailed comments, this is getting rather interesting. This whole subject of class kerning is a really complex and potentially messy task even though one might expect it to be well-suited for an algorithm. After the exchange today, I feel there are two approaches to class kerning: Se...

Btw, I just published a Kern On update: https://kern-on.com/update/ Special-spaced pairs are more likely to be zero. Less noise! BIG news: autospacing is now persistent! This makes it easier to avoid unnecessary or accidental small kerning pairs against the “neutral sides” such as the flats in sans-...

Can you explain what exactly “noise” means in this context, and what the disadvantage is, from a rational point of view?

My (maybe too naïve) logic is the following: if I have a kerning pair of -60 units for, let's say, /questiondown.case/W, I would prefer it stay in the final font rather than a kerning pair of +3 even for a combination such as /n/o. Sorry, I disagree. I’d rather keep a 3-unit value for /n/o then a -...

Oh, I see, this means I am creating Kern On, and make decisions, effectively not only for my users but also for my users’ clients. Which makes communicating these things a little more difficult. but can I ask what Kern On does if it finds that a class kerning pair in all masters is very small? I’ll ...

I would also like to add my mustard to the discussion, since this is something that comes up regularly when I work on client projects. My main question is why .case variants are treated as less important than their normal counterparts. I would expect them to be treated with the same importance. Are...

It’s a bit difficult to tell without seeing the font. First, it seems you are using manual kerning groups? Are you sure you need a kerning group for the left side of the J (I assume /J and /Jcircumflex)? It may be better to leave it away. 2) Non-corpora pairs should be ignored during the optimizatio...

Sorry about that. A crash should never happen, no matter what. Would you mind sending me the file? Then I can have a closer look. Thanks!

Thanks for the file! I just fixed the crash (which was a very old little bug, actually). It will be included in the next update for everyone.

Some thoughts on the questions you raised: [...] which results in a larger filesize. [...] Filesize without kerning: Static Fonts: 66 kb Variable Fonts: 170 kb Filesize with KernOn set on 60kb: Static Fonts: ca. 126 kb Variable Fonts: 428 kb It seems you are referring to uncompressed desktop fonts? ...

I just tried and it does not crash. Could you send me the file?

Good to know! Sometimes computers are funny. It may have been Glyphs providing the wrong advance width via the API, which sometimes happens.

Thanks for your feedback. Yes, this is sensible and I have had somewhat similar requests, and ideas of my own. In future, I am planning to implement a feature that outputs a test text (based on my https://justanotherfoundry.com/generator), that includes those pairs that would be next in line as sugg...

Could you send me the file? It is hard to tell without seeing it in more detail. Thanks!

Not sure what exactly is going wrong, from seeing this image. What would be the expected result, and why?

Sorry, the built-in search function of this forum is not very powerful. I am using this PHP-based forum named phpBB, which is rather clumsy but I haven’t found anything neater that works without root access to the server. Usually googling with site:kern-on.com works. Maybe something like this? https...

Yes, non-existing pairs defined as a model in the userData are considered to be zero.

However, if the font has no kerning pairs at all then it is considered to be untouched even if Kern On data exists in the userData.

What you describe is exactly the idea behind the model suggestions. The suggested pairs are practically Kern On asking, me how would you like these handled, and/or, please check this pair. What exactly is different in the method you have in mind?

Hello Daniel, sorry to hear you are having this problem. Would you mind sending me the file? Then I can have a closer look.

Yes, please!

Glad it worked! I need to double-check in the code why it may not have started from scratch in your case. (The Kerning Window has the option to filter the pairs that are displayed. You may have selected and removed all, but in fact there were some hidden ones left.)

Hello Diego, I’d suggest you open the Kerning Window (⌥⌘K) while Kern On is not running, and delete everything there (select all and click the little minus button). As you start Kern On again, it will give you a fresh start. Certain data such as the special spacing settings are retained so it is not...

Yes, Ethiopic is supported by Kern On. I added it at a user’s request at some point, and I believe it has been used on real-world projects. Just give it a try and let me know how it works for you!

This sounds strange. Would you mind sending me the file? If the shapes of o and e are virtually the same on the left then they should receive the same kerning. Without seeing the file, the only thing I can imagine is that the e or the o has special spacing.

Good to know!

Sorry, no news. It is definitely on my list of future improvements, though!

I quickly checked a few fonts on my computer and couldn’t find any that have kerning between Hebrew and period or asterisk. What’s the current best practice?

Thanks for the file. It took a while to understand what is going on but here is the explanation: Your font contains RTL kerning. Kern On currently does not support RTL autokerning but it preserves existing RTL kerning, including the kerning groups. Since asterisk and period are kerned RTL, their ker...

Could you send me the file? Then I can have a closer look.

Which glyphs do you kern the arrows against?

I spent considerable time improving the speed of Kern On but there are limits as to what you can do. To me, the crucial aspect was the speed of the tool while you are working on your kerning, the reaction time as you set or change models, for example. I believe this is fairly snappy now. During fina...

If you have many user-set autopairs then that means you are working with fonts for languages (and characters) that are not supported by Kern On yet? There are several possible solutions to your problem: 1. Go to one master that has all the required user-set autopairs, then click on the little arrow ...

Can you explain why you would want that instead of normal quantization?

Good news! The bug in Glyphs has been fixed. If you update to the latest cutting-edge Glyphs version (or use the latest stable version) things should work as expected.

Thank you for sending the file. There seems to be a bug in the latest cutting-edge Glyphs version (3316). With Glyphs 3260 (the current stable version) and with Glyphs 3300 (this is just a somewhat older version I have) I am getting the expected, consistent Kern On behaviour in a, n and u. Also, if ...

You can send it to me by e-mail (see the footer on https://kern-on.com/). Thanks!

This is strange. Maybe the right side of the a has special spacing (or, n and u have special spacing)?

You can also send me the file if you don’t mind, then I can have a quick look myself.

Working with connected scripts should work with Kern On. I personally haven’t tested this very much yet. The workflow should be similar as for unconnected fonts, though. In case you have alternates that should never be kerned on one side then it is probably easiest to use the “No kerning” property t...

It is also possible that your font has many kerning pairs, and you can reduce the number. Maybe there are lots of pairs that should not need kerning? You can use the pairs drop-downs on “neutral” glyph sides to detect other glyphs that lead to unnecessary non-zero pairs because they are not spaced c...

This should answer your question:
https://kern-on.com/manual/#q-compression-artifacts

To keep the pair during the final kerning, you can try to increase the data size (kB).

mekkablue wrote: ↑25 Jul 2024 That way, the substitutions are visible to KernOn, I assume?

Kern On sees whatever is inside GSFont.compositorFont. It does not look at the feature code at all.

See https://kern-on.com/manual/#which-pairs-are-kerned

In this case, you could remove the “#ifdef Variable” … and remove the feature in all static instances. You mean, Jeremy as the user, or would Kern On do this internally? One solution could be that you check the font but instead of automatically ignoring those glyphs, ask the user. Or do not check a...

Kern On does not parse the feature code by itself. Instead, it asks Glyphs for a compiled version, and then browses the lookups. As it seems, by default, Glyphs doesn’t include the substitutions you are showing above, when I call the property GSFont.compositorFont. The question is, how can Kern On g...

This is strange. You mean, after pushing the Kern On button and finalizing the kerning, and then re-starting Kern On, some models are lost? In other words, the number of model pairs as shown in the bottom section is smaller than it was before pushing the Kern On button? This should never happen. Whi...

Not sure how I can help you with that. As you stopped using Kern on, this question is not about Kern On, it seems?

Can you explain step-by-step what you are doing, and how Kern On is involved?

Sorry, can you explain in more detail?

Yes, “No kerning” is probably the solution in this case. Note that you can simply select several glyphs and set it for all of them.

Kerning groups are not a safe way of seeing whether Kern On kerns a glyph (even though this is an indicator). Can you have a look at whether the glyphs in question have any kerning? While Kern On is running, you can also use the “Pairs” drop-down menu to check this. The next thing to check is whethe...

Keep in mind that using cvXX instead of ssXX is not just a work-around for the “Kern On world”. It’s simply the correct OpenType feature for the task, not just internally in your font editor but also when you export and distribute the fonts.

This was surprisingly easy to implement. Thanks for the nudge!

The next Kern On update will support cvXX, which means it will autokern any possible combination of alternates accessed via cvXX.

Thanks for the file, Ryan. Looking at your list of user-set autopairs, there are different reasons for pairs not being autokerned by default: • /s.ss01/ecircumflex is not autokerned because /s/ecircumflex is not autokerned. If this pair is important to you you’d probably want to set /s/ecircumflex a...

Thanks for your help, Brian. Yes, using custom kerning groups could be a good work-around.

Ryan: Would you mind sending me the file? Then I can have a look and either improve Kern On or possibly find a way of getting this to work with the current version.

Jeremy Tribby wrote: ↑04 Apr 2024 Would it be helpful to have specific examples of this as OpenType feature code (and/or Glyphs specific format for VF), so that a suitable UI could be worked out from there?

Yes, that would be great!

I see. This brings up the same old question : “Find all composites in which the positioning of the components is affected by kerning.” This was surprisingly difficult to implement, as you remember, even with Georg’s help. To be honest, the current code never felt very robust to me, and now we are se...

Whether to autokern non-exporting glyphs is an interesting question. At first glance it makes sense to automatically exclude them but there can be non-exporting glyphs in a font that should be autokerned, e.g. for fractions. So, the approach is to generously generate autokerning pairs and then disab...

Thanks for the explanation and the workaround, Georg. I still don’t understand why you consider shouldAttach = False to be the correct return value in a case like this. The diacritic component is clearly attached (i.e. its position depends on the anchors). From a functional point of view, it does no...

Thanks for sending the file. Seems like we were not looking at the same file! Very similar but not identical, which made it easy to dig into it. As it turns out, the PUA values for the .case accents are causing this strange behaviour. What I tested: • Open your latest file (with PUA for the .case ac...

What happens if you run the script in Glyphs 3.2? I cannot run any Python scripts in Glyphs 3151 because Glyphs says it cannot not find a compatible Python version. One thing I noticed is that Hmacron seems to be completely unknown to my version of Glyphs. It doesn’t have a Unicode value and Glyphs ...

Btw this is a script that can be used to inspect what Glyphs returns for certain layer and component properties: for layer in Font.selectedLayers: print( layer.parent.name, 'hasAlignedWidth', layer.hasAlignedWidth() ) for c in layer.components: print( c, 'shouldAttach', c.shouldAttach() ) print() In...

This is strange. If I open the font with Glyphs 3249 and Kern On 1.31 then /H/macroncomb.case is not autokerned. Which version of Glyphs are you working with?

Thanks for your help, Sebastian. I definitely found the reason why the default groups were not set properly. They were set in the KO engine but not written to the userData in Glyphs. This discrepancy is the reason for the funny behaviour between the very first start with a font, and the next re-star...

Thanks for the explanation! I think I found the problem and fixed it.

Can you confirm: Setting the special spacing group only fails when starting with a fresh font, and before re-starting Kern On. Is that correct? Once you re-start Kern On, all behaviour is as expected, right?

Hello both of you, sorry about this. This is really frustrating for me as well because I really cannot reproduce the problem. Of course, I can see that it is happening in the video. Thanks for the detailed analysis, Alex. Seeing 1 vs 3 is very strange. Was the “Parenthesis” group one you created you...

As long as you don’t lose models or independents because of the crash, you can just finalize again. (Keep in mind that all kerning except models and independents is “lost” the moment you start Kern On).

Kern On | Kern On forum

Search found 437 matches