Kern On

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).

Yes, we finally got it to work last week! I sat down with Georg to resolve this. It will be included in the next release.

Do you want me to send you my current in-house version if it’s urgent?

Some options are explained in the manual: https://kern-on.com/manual/#font-settings
Does that work for you?

You can just reply to your purchase confirmation e-mail, or use the one given in the footer at https://kern-on.com/

This is really difficult to answer without having the font file, I am afraid. Would you mind sending it to me?

This is really difficult to answer without having the font file, I am afraid. Would you mind sending it to me?

Hello everyone! I finally assembled a proper user manual:
https://kern-on.com/manual/

Some explanations are rather detailed – they might be interesting if you want more in-depth information than what’s shown in the videos.

Hi Brian, Thanks for your detailed feedback. Some of this is impossible to comment on without having the file or seeing more details, some of which I will try to answer here. Regardless of what font I’m working with in KO, I’m finding that with essentially any letters that have extremes amounts of n...

This does look a bit strange indeed. Would you mind sending me the file?

As a side note, one thing I noticed (although it does not explain the behaviour) is, why does the V have larger sidebearings than the W? I’d expect them to be the same or smaller.

It turned out to be a UI glitch. The list of special spacing groups simply did not get updated when we activate a different file (if KO is running for both files). Just fixed this. Btw, the old special spacing groups are still available in the drop-down menu after "Sync kerning types from"...

Hmmm... scratching my head.

This only happens if KO is running for both files. You could open both files, start KO for the target font and sync. Then close the other file.

It’s probably a bug, will have a closer look. Thanks for the notice.

One thing I noticed is that it does not import special spacing groups. No, this is a separate feature. It is called “Sync kerning types from”, also in the (•••) menu. “Kerning type” means special spacing, standard kerning or no kerning. If you want to transfer both then you should first transfer (s...

Thanks for the scripts, Manuel! But compared to the 2–4% with your palettize script I was getting a much better improvement in file size. This figure was just what I found back then, from a handful of files I was generating at the time. Comparing the saving to the overall file size is not a very sen...

KernOn keeps telling me the right side bearing of my B is too tight so it kerns it away from the H by 7. Visually it’s now too loose to my eye, so I make a model pair and set it to zero. Yes, that’s the way to go! But now that affects my nn pair, which is also a model pair set to zero. That’s impos...

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.

You should definitely not set the left side of the /n to “No kerning” as there are many combinations with /n as the second glyph that require kerning.

I’d strongly advise against using “No kerning” for any letters.

If you currently use multiples of 8 at 1000 UPM, you can re-scale the font to 125 UPM as 1000 / 8 = 125.

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 a...

Thanks for your work, Manuel! There was lots of extensive Kern On feedback coming in today so I will need a few days to have a proper look at it and write the thorough answer it deserves. Miyamoto, it seems you are working with 1000 UPM but then place everything, including contour points, spacing an...

There were similar requests before. My feeling is that the main motivation is to keep things “tidy under the hood”. This seems to be a strong (though irrational) desire among many designers, which I initially underestimated. I will soon implement the quantisation of the autokerning values (multiples...

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.

Can you explain what exactly “a limited amount of kerning pairs” would be? Also, what exactly are you trying to achieve? Not sure I understand.

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 rea...

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 ...

Yes, that’s exactly the problem.

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. ;-)

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...

> 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...

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%.

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 accordi...

Class kerning (groups, as Glyphs calls it) is not necessarily better in this case: Three glyph-glyph pairs cost 3 * 4 bytes plus overhead for the first glyph. Writing these pairs into the class kerning table will add a row to the table, which costs 2 bytes per cell plus class definition overhead. Wr...

Maybe you omitted the .split() at the end of the first line?

This code should do practically the same but it is more complicated to set up. ;-)

You can also work with glyph names, with space in-between: characters_1st = 'f.calt g.calt t.calt f.liga t.low e.ss04'.split() characters_2nd = 'Aacute Abreve Acircumflex Adieresis Agrave Amacron Aogonek Aring Atilde AE Cacute Ccaron Ccedilla Ccircumflex Dcaron Dcroat Eth Eacute Ecaron Ecircumflex E...

This seems to be a unique use case. Right now, there is no elegant, built-in way of achieving what you want. Maybe I should add a feature that allows to specify user-set autopairs for groups of glyphs. For now, you can use this code: characters_1st = '◆■‣•' characters_2nd = 'ÁĂÂÄÀĀĄÅÃÆĆČÇĈĎĐÐÉĚÊËĖÈĒ...

I suppose you refer to the little lock symbol in Glyphs next to the kerning value? It’s just how Glyphs shows you whether a pair is a class-class pair (locked icon) or a glyph-glyph pair, a.k.a. exception (unlocked icon). It’s a strange visualisation as class-class pairs are not protected (“locked”)...

Sorry you are not getting the results you expect. It’s a bit difficult to tell what is going on without seeing it myself. Would you mind sending me the .glyphs file? Then I can have a closer look. It is not unthinkable that there is a small slip somewhere in the code that causes wrong output in your...

Sorry for not answering to your reply quicker. a user-specified filter into the step between where the deviations are calculated and when they are multiplied by the frequency of the pair. I don’t think being able to customize this value is necessary. It is not really a mater of taste and I believe a...

When Kern On determines the suggestions, the objective is to “fill the gaps” in the cloud of models. It should suggest pairs that have a shape combination which is not similar to any of the existing models, and therefore the engine (all models combined) currently has a “loose grip”, i.e. you will ty...

I can’t test the script in 3.1.2 as it complains about missing Python 3. I am certain that is worked at some point, as I tested it when I implemented it in February 2023. In any case, I think what Kern On needs to detect is clear: Composites in which kerning affects the positioning. It would be very...

Using this code: for layer in Font.selectedLayers: print( layer.parent.name, 'hasAlignedWidth?', layer.hasAlignedWidth() ) for c in layer.components: print( c, c.alignment, c.alignmentType() ) print() I am getting this output: onehalf hasAlignedWidth? True <GSComponent "one.numr" x=0.0 y=0...

Next attempt: for layer in Font.selectedLayers: if not layer.hasAlignedWidth(): continue pairs = [] prevComponent = None for c in layer.components: if c.alignment == 0 and prevComponent and prevComponent.alignment == 0: if c.alignmentType() == 3 or prevComponent.alignmentType() == 3: pairs.append(pr...

Btw, I am working in Objective C, of course. Georg, you can see the current code in the shared Github repo.

You mean something like this? for layer in Font.selectedLayers: if not layer.hasAlignedWidth(): continue kernedComponents = [] for c in layer.components: if c.alignment == 0: kernedComponents.append(c.name) if len(kernedComponents) >= 2: print( layer.parent.name, kernedComponents ) No, this also cat...

the fact that every launch is a new day means you have to proof *everything* after each correction, having no clue where to expect changes. This is exactly what the “Compare to” functionality is for. Just save the old version as a separate snapshot file, then start Kern On, make the changes, open t...

I need to identify composite glyphs in which the positioning of the components is affected by kerning.

Thanks for pointing this out. It’s not too difficult for me to implement the application of the font’s grid. I’ll add that to my to-do list.

Another possible work-around would be to work with a UPM of 20 (if your grid is currently 50 units at 1000 UPM). This is what I would do anyway, I guess.

Thanks for the file. This is a bug in Glyphs that was introduced at some point in 2023. I reported it to Georg in December. To demonstrate it you can use: for layer in Font.selectedLayers: print( layer.parent.name ) for c in layer.components: print( c, c.alignment, c.alignmentType() ) print() In som...

Hello, I seem to remember this was a feature introduced with some update a while back: glyph combinations that are used as components in other glyphs (such as /one.dnom /fraction in /onehalf) were kerned by Kern On, regardless of importance on the pair frequency list. Yes, this is how it should wor...

What exactly is it that is not working in the other masters?

Can you send me the file? Then I can have a closer look. Thanks!

Are the .italic glyphs accessible via any OT feature? In other words, is there any OT feature that has something like sub f by f.italic? If there isn’t then Kern On does not generate the auto-pairs for these glyphs. (The roboty answer would be that this means that in the exported font, these glyphs ...

As of today, is implemented in the latest version: Kern On now generates local models automatically when you un-autokern a master. You still get some warnings but Kern On is playing a trick: These warnings suppressed at first; they are only shown once you start modifying or setting new models, or if...

Good news! This problem should be solved. Get the latest update from https://kern-on.com/update/ and don’t forget to restart Glyphs!

Please let me know if you run into this problem again.

Update: I managed to reproduce this. Stay tuned.

This is tricky to answer without seeing the font. Kern On never thinks a pair is too tight as such, it only thinks it is it is too tight compared to another pair. For example, when it says “дл is too tight compared to vn” it might as well say, “vn is too loose compared to дл”, with the same meaning....

I will try to reproduce this problem. The challenge here is, this text field is an interaction between Kern On, Glyphs (because KO uses an Objective C class provided by Glyphs), and macOS, of course. Any change in any of the three can potentially trigger this wrong behaviour. Would you mind letting ...

Sorry, this video seems to be private. YouTube doesn’t allow me to see it.

Kern On | Kern On forum

Search found 381 matches