Kern On

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

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

Kern On | Kern On forum

Search found 405 matches