Controlling kerning groups

Post Reply
User avatar
SCarewe
Posts: 45
Joined: 23 Apr 2021

Controlling kerning groups

Post by SCarewe »

Hello, this is probably an outlandish request, but I am pretty confused as to how KO achieves its kerning group decisions. I'm sure there are good reasons which I simply don't understand, so maybe somebody else here can explain what's going on. First example: |o has the kerning group e (which, technically, makes sense, I guess, but I would personally much prefer calling it o). n| has kerning group a, but is always treated as an exception, as my a| is a different shape than my n| – why does KO even put n and a into the same group? Also, why is no treated an an exception for both classes, with 0 kerning (in both masters!) while ne is regular class kerning with no kerning? Same classes. Doesn't make sense to me.

I've mentioned this before, but just to have it in a thread about kerning classes again: I sincerely hope that, in the final (paid) version, kerning classes can be named differently than KO_ – not just for aesthetic reasons, but that makes understanding and editing the kerning a lot more approachable, such as in this case.
Attachments
2021-05-12 20.17.38.jpg
2021-05-12 20.17.38.jpg (43.9 KiB) Viewed 2375 times
User avatar
SCarewe
Posts: 45
Joined: 23 Apr 2021

Re: Controlling kerning groups

Post by SCarewe »

Ah, regarding the a and n, here's what I mean. n| is registered by KO as KO_a kerning class, which makes no sense. KO of course realises this to some extent and makes all kerning and exception for n|. You can see how n and a have completely different shapes on the right, so I wonder why they are lumped into the same group.
Attachments
2021-05-12 20.23.51.jpg
2021-05-12 20.23.51.jpg (44.76 KiB) Viewed 2374 times
User avatar
Tim Ahrens
Site Admin
Posts: 183
Joined: 11 Jul 2019

Re: Controlling kerning groups

Post by Tim Ahrens »

I just posted two answers in another thread, hope they also clarify things for this one.
SCarewe wrote: 12 May 2021 Hello, this is probably an outlandish request, but I am pretty confused as to how KO achieves its kerning group decisions.
I’ll improve that soon, I hope.
SCarewe wrote: 12 May 2021 |o has the kerning group e (which, technically, makes sense, I guess, but I would personally much prefer calling it o).

named differently than KO_ – not just for aesthetic reasons
You mean, aesthetic reasons when you look at the font in your editor? See my reply over there.
User avatar
Tim Ahrens
Site Admin
Posts: 183
Joined: 11 Jul 2019

Re: Controlling kerning groups

Post by Tim Ahrens »

By the way, you can always batch re-name the kerning groups if you open the .glyphs file in a text editor and replace KerningGroup = KO_ with KerningGroup = .
User avatar
SCarewe
Posts: 45
Joined: 23 Apr 2021

Re: Controlling kerning groups

Post by SCarewe »

Thanks a lot for the renaming tip, I didn't think of that! While now manually digging through the kerning (and finding loads of – in my opinion – pretty useless kerning, like zero.superior fraction), I noticed that, for instance, D| was set to kerning group H. KO realises, of course, that this doesn't make sense, so all the kerning on D| was set to exceptions (and also kerned against only exceptions of one repeating component glyph, like D Iacute, D Icircumflex, D I dotaccent, etc. – all with the same kerning value, but D and all the Is were both set to eceptions). Why does this occur? Why does KO set D| kerning group to H? There are other occurences, like E| being set to I (which then is set to mostly exceptions when kerned against other glyphs), |AE being set to A, but |AEacute being set to AEacute, B| is also set to H, |Ecaron is set to Eogonek while all the other |Es are H ... Sure, in the end, it may not make much of a difference, regarding your post on type designers rather than font designers, but even as a type designer I would prefer not to work with a big mess of a file :) I'm happy to send over the glyphs file, if that helps. Thanks!

Edit: After some more digging, I found that a lot of UC| is set to H: B|, D|, F|, J|, M|, O|, P|, S|, U|, Germandbls|, Schwa|, U|, W|, Omega|. That is half of UC, in addition to the ones that fit H|. KO realises, of course, that this doesn't fit at all, so these are all kerned as exceptions, which makes a lot of the kerning very confusing (and generates loads of unnecessary data). Any chance this could be cleaned up by KO, instead of me going through it all manually?
User avatar
Tim Ahrens
Site Admin
Posts: 183
Joined: 11 Jul 2019

Re: Controlling kerning groups

Post by Tim Ahrens »

SCarewe wrote: 18 May 2021 pretty useless kerning, like zero.superior fraction
That’s debatable, of course. There are fonts that do not make a distinction between numerals and superiors – the one I am currently working on, for example. So we need all superiors before and inferiors after the factions, as the user of the font might use them to create arbitrary fractions.

Anyway, thanks for the feedback. It helped me spot a small error in the scripts that generate the pairs list, where there was a fraction instead of a slash. I also reduce the priority value of the superior-to-fraction, so they are less likely to eat up the precious space if you set a small data volume as you generate the full kerning.

Regarding the generated class kerning: As I said, I am working on improving that. In fact, the update I posted today (0.9b18) should already give better results and I hope to improve it further. However, can I remind you again that “cleaning up” the kerning so that it looks pretty in your font editor is not a rational goal. The only thing that matters is the rendering of final font.
christinapoth
Posts: 4
Joined: 23 May 2021

Re: Controlling kerning groups

Post by christinapoth »

Dear Tim,

there is probably a very easy way to add alternative glyphs manually to a kern group? For example this seven.ss01 that I want to behave like the seven in the first line.

What would be the best way to do this?
Thank you!!
Christina
Attachments
Screenshot 2021-05-23 at 17.02.23.png
Screenshot 2021-05-23 at 17.02.23.png (260.36 KiB) Viewed 2322 times
User avatar
Tim Ahrens
Site Admin
Posts: 183
Joined: 11 Jul 2019

Re: Controlling kerning groups

Post by Tim Ahrens »

Sorry, it is not possible to set kerning groups manually.

While Kern On is running, there are no kerning groups, only glyph-glyph pairs (existing kerning groups are erased when KO starts up).

Kerning groups are generated automatically when you complete the kerning (i.e. using the “Kern On” button). If you re-start Kern On, these kerning groups will be erased again (but the previous models and everything else will be correctly restored, of course).
User avatar
Tim Ahrens
Site Admin
Posts: 183
Joined: 11 Jul 2019

Re: Controlling kerning groups

Post by Tim Ahrens »

By the way, it’s strange that the lower seven is not kerned at all. Is that the seven.ss01? Have you set up the OpenType feature? It’s necessary for Kern On to know that the pair (potentially) needs kerning. I suggest to have a look at the “Under the hood” video (starting at around 4:20).
christinapoth
Posts: 4
Joined: 23 May 2021

Re: Controlling kerning groups

Post by christinapoth »

Hello again!
“By the way, it’s strange that the lower seven is not kerned at all. Is that the seven.ss01?”
Yes, it is the seven.ss01 — I don’t it understand either. Yes, OT feature is set.
… strange
User avatar
Tim Ahrens
Site Admin
Posts: 183
Joined: 11 Jul 2019

Re: Controlling kerning groups

Post by Tim Ahrens »

Did you set the OT feature while Kern On was running? Sorry, I haven’t made clear that this will not be noticed by Kern On without a re-start (of KO, not Glyphs).

In fact, you shouldn’t make any major modifications to the font while Kern On is running as it will either not realize, or possibly even crash. This is not tested very well, I must admit.

The only editing of the font that is supported while KO is running is the changing of kerning values (which behaves the same as changing them on the KO panel), changing the sidebearings, and changing the contours. These edits will be updated in Kern On. For all other changes to the font I’d recommend to switch off Kern On.
rosaiani
Posts: 8
Joined: 24 Apr 2021

Re: Controlling kerning groups

Post by rosaiani »

One thing that is bugging me about the generated kerning groups is glyphs with diacritics receiving their individual kerning groups. I haven't yet done something like that in previous fonts ever so I'd think that KO_o = KO_oacute always - component glyphs should probably inherit the kerning groups of the base glyph in 99% of the cases, don't you think?
Gini
Posts: 18
Joined: 23 Apr 2021

Re: Controlling kerning groups

Post by Gini »

This (what @rosaiani said) is giving me extra work when checking kerning after KO.
I understand that the plugin "reads" the mass of paths in the sides, and diacritics may change that, but I found many cases where I just had to change the group of a composite glyph to make it work.

Maybe there could be a way to "force KO to maintain referred glyphs in the same group",, or something like it.
User avatar
Tim Ahrens
Site Admin
Posts: 183
Joined: 11 Jul 2019

Re: Controlling kerning groups

Post by Tim Ahrens »

I’m a bit surprised that some users find it important to control the kerning groups that are generated.

In the above example: If the groups KO_o and KO_oacute are merged then that would result in different class-class kerning, different glyph-glyph pairs (a.k.a. exceptions) but the rendering of the font would not change. Different groups lead to different exceptions, and the same result in the end.

Considering that setting kerning groups manually would not affect the final rendering, why would you want to do so?

If, with the proposed different groups, the rendering is identical, how would that mean less work when proofing?
Gini
Posts: 18
Joined: 23 Apr 2021

Re: Controlling kerning groups

Post by Gini »

Hello, Tim.
There's no problem in having different groups with the same result, of course. I understand that having control over this is not a part of the KO workflow you created.

The thing is I'm not having an identical rendering in every pair.
I've had, for example: LŸ different from LY, and other Y with diacritics that didn't influence in the kerning of this specific pair, so I changed their group to KO_Y to make it work.
User avatar
Tim Ahrens
Site Admin
Posts: 183
Joined: 11 Jul 2019

Re: Controlling kerning groups

Post by Tim Ahrens »

Thanks for the explanation.

It seems the real problem is that LŸ and LY have different kerning, the issue is not the kerning groups. So, we need to fix the inconsistent kerning in LŸ vs LY rather than setting the kerning groups differently.
If Kern On allowed you to set groups manually, and it thinks LŸ and LY have different kerning then it would create an exception pair and nothing is gained. Setting the groups manually would not solve the problem.

Which version of Kern On are you using? Versions older than 0.9b17 sometimes produced funny results such as this but it should not happen in the current version any more. If you encounter a mismatch such as this, would you mind sending me the file? Then I can have a closer look.
rosaiani
Posts: 8
Joined: 24 Apr 2021

Re: Controlling kerning groups

Post by rosaiani »

On my latest trial, the results were much better than last time, indeed.
Gini
Posts: 18
Joined: 23 Apr 2021

Re: Controlling kerning groups

Post by Gini »

I admit that I started using a mixed workflow, adjusting pairs after KO in a project, so I can't be sure about what version I used back when I clicked the KO button.
But soon I'll use the latest version again and check everything, then I'll get back here to tell my impressions and send my file to Tim if that's the case.
:)
Gini
Posts: 18
Joined: 23 Apr 2021

Re: Controlling kerning groups

Post by Gini »

Hello, Tim!

I'm still having this kind of output (latest version of KO)

And since I'm already advanced in checking all kerning, I don't feel comfortable to get back into KO and make a new model, for example, because this could change other pairs, and I'd have to take a look at everything over again; so I'm manually adjusting these matters, directly in Glyphs
Attachments
Screen Shot 2021-07-28 at 19.42.59.png
Screen Shot 2021-07-28 at 19.42.59.png (16.76 KiB) Viewed 1860 times
Screen Shot 2021-07-28 at 19.38.21.png
Screen Shot 2021-07-28 at 19.38.21.png (41.29 KiB) Viewed 1860 times
Screen Shot 2021-07-28 at 19.33.36.png
Screen Shot 2021-07-28 at 19.33.36.png (29.18 KiB) Viewed 1860 times
User avatar
Tim Ahrens
Site Admin
Posts: 183
Joined: 11 Jul 2019

Re: Controlling kerning groups

Post by Tim Ahrens »

Thanks for posting these images.

Are you looking for advice what to do now (without using Kern On), or are you suggesting Kern On should behave differently?
Gini
Posts: 18
Joined: 23 Apr 2021

Re: Controlling kerning groups

Post by Gini »

I forgot to say, but maybe that's relevant for KO, that these glyphs (/a and /e, that were kerned only when they don't have diacritics) are alternates.

About what you asked, I'm already dealing with how to make these corrections, but I'm not completely sure that I'll cover everything, so of course any advice is welcome!
Anyway It would be great to, at some point, trust KO to deliver this.
User avatar
Tim Ahrens
Site Admin
Posts: 183
Joined: 11 Jul 2019

Re: Controlling kerning groups

Post by Tim Ahrens »

Sorry, I’m somewhat confused. What exactly is your question or suggestion?
Gini
Posts: 18
Joined: 23 Apr 2021

Re: Controlling kerning groups

Post by Gini »

Is there something I should have done in KO for these glyphs to be correctly kerned?
Or was it something that the plugin should have done already and haven't?
User avatar
Tim Ahrens
Site Admin
Posts: 183
Joined: 11 Jul 2019

Re: Controlling kerning groups

Post by Tim Ahrens »

I assume you are saying the pairs in your images are not correctly kerned, is that right? What exactly is not correct?
Gini
Posts: 18
Joined: 23 Apr 2021

Re: Controlling kerning groups

Post by Gini »

Yes, that's right.
I think the glyphs with diacritics should have the same kerning values than the ones without diacritics, at least most of the time. In the examples I sent, I can't understand why Ya is kerned, and Yá has no kerning at all; when I see it in a text, this lack of kerning in Yá stands out (this is how I found it out).
User avatar
Tim Ahrens
Site Admin
Posts: 183
Joined: 11 Jul 2019

Re: Controlling kerning groups

Post by Tim Ahrens »

So, you are practically saying there shouldn’t be any class kerning exceptions? I think it’s crucial that exceptions are part of the kerning strategy. Otherwise, combinations such as Tö or, quite often, Té as in your example above, are exceptions or they will be too tight.

So, working completely without exceptions is out of the question for me, I am afraid.
User avatar
Tim Ahrens
Site Admin
Posts: 183
Joined: 11 Jul 2019

Re: Controlling kerning groups

Post by Tim Ahrens »

I agree that some combinations in your images above seem too loose. However, disabling exceptions can’t be the solution.

It‘s difficult to tell purely from the images, though. How many models do you have in your font? Were there any warnings you ignored? That would force KO to loosen the grip on the autopairs by certain models. Which are the models that define the autokerning for Ya, and which for Yá? What if you set Ya as a model? Does that lead to sensible kerning for Yá? You can also send me the file so I can have a closer look.
Post Reply