Hello. I have come across a question that doesn't seem immediately resolvable to me with Kern On. For math operators, I want to set them to No Kerning among each other, so that no math operators receive kerning against other math operators. But I still want things like 7+7 to be kerned. So, ideally, for math operators, I would like to set a group-specific spacing rule of No Kerning against other math operators, but normal kerning against numbers.
Is this possible? Thanks a lot!
Group-group-specific kerning rules
- Tim Ahrens
- Site Admin
- Posts: 437
- Joined: 11 Jul 2019
Re: Group-group-specific kerning rules
Agreed, sometimes it would be handy to specify things such as no kerning between certain groups of glyphs. Similarly, you may want special spacing between certain groups but not others. Right now, Kern On allows to have an individual special spacing value within one group, i.e. if both glyphs are from that group. For example, I want the superiors to have generous special spacing against letters but not within themselves. This is something that’s detected automatically of you set the models.
Maybe I should add a proper “special spacing manager” dialogue that allows to set these things in detail?
For now, a work-around for you would be to generate all math-math pairs via a simple script, and then set these pairs to independent zero pairs. Not an elegant solution, though, I have to admit.
Maybe I should add a proper “special spacing manager” dialogue that allows to set these things in detail?
For now, a work-around for you would be to generate all math-math pairs via a simple script, and then set these pairs to independent zero pairs. Not an elegant solution, though, I have to admit.
Re: Group-group-specific kerning rules
Hello, thanks a lot for your thoughts. A special spacing manager would be great for (optional) granular control. The automatic detection works very well so far, but for cases like the one outlined above, more specific controls would be very useful.
I will try your suggestion, for the time being, it's a decent, simple solution.
Thank you!
I will try your suggestion, for the time being, it's a decent, simple solution.
Thank you!
Re: Group-group-specific kerning rules
Hi
Downloaded and bought the app today, so still a newbie.
I have similar cases; I don't want to kern punctuation with numerator etc, if I remove the kerning pair between five.numr and period, Kern-On wants to remove a lot of incompatible models with that pair that are actually correct, and can't do anything until I close and reopen the app. On the other hand, it doesn't want to kern dnom and numr figures with the fraction sign. I am pretty sure I set up the special spacing category correctly.
The special spacing manager would be a great and necessary addition imo.
Cheers
Downloaded and bought the app today, so still a newbie.
I have similar cases; I don't want to kern punctuation with numerator etc, if I remove the kerning pair between five.numr and period, Kern-On wants to remove a lot of incompatible models with that pair that are actually correct, and can't do anything until I close and reopen the app. On the other hand, it doesn't want to kern dnom and numr figures with the fraction sign. I am pretty sure I set up the special spacing category correctly.
The special spacing manager would be a great and necessary addition imo.
Cheers
Re: Group-group-specific kerning rules
Hi Rosalie, concerning fraction kerning (which is still not automatically done by KO for some reason), I wrote a script:
https://github.com/eweracs/glyphs-scrip ... ter/KernOn
It's called Set Fraction Autopairs.
https://github.com/eweracs/glyphs-scrip ... ter/KernOn
It's called Set Fraction Autopairs.
- Tim Ahrens
- Site Admin
- Posts: 437
- Joined: 11 Jul 2019
Re: Group-group-specific kerning rules
You are right, support for numr, dnom, sups, subs and sinf is not very refined yet.
As a general principle, Kern On has a list of Unicode pairs, which is then “extended” by applying all sort of features (in all sorts of combinations), to generate additional glyph-glyph pairs. “All sorts” has a few tweaks, such as not generating smallcap-to-lowercase pairs, or ignoring tnum.
What would be the best strategy for numr, dnom, sups, subs and sinf? In theory, we want to kern all pairs that may result from the activation of features. However, that leads to lots of pairs that are not relevant in practice. I generally try to have hard-coded (or rather, too specific) rules but maybe here it would make sense from a practical point of view. Something similar to Sebastian’s script. I’ll try to find a solution for that.
As a general principle, Kern On has a list of Unicode pairs, which is then “extended” by applying all sort of features (in all sorts of combinations), to generate additional glyph-glyph pairs. “All sorts” has a few tweaks, such as not generating smallcap-to-lowercase pairs, or ignoring tnum.
What would be the best strategy for numr, dnom, sups, subs and sinf? In theory, we want to kern all pairs that may result from the activation of features. However, that leads to lots of pairs that are not relevant in practice. I generally try to have hard-coded (or rather, too specific) rules but maybe here it would make sense from a practical point of view. Something similar to Sebastian’s script. I’ll try to find a solution for that.
Re: Group-group-specific kerning rules
Hello, have you had any time to consider this further? Especially for maths operators. I don't quite understand why Kern On kerns maths operators amongst each other in the first place, or is this just a by-product of them being set to some type of kerning in the first place?
I did simply add them to independent pairs (with one stylistic set, that makes 290...), but that renders it rather complicated to re-work independent pairs that get set by Kern On when a model is rejected. Not sure whether splitting into Independent Pairs and Rejected Pairs makes sense, but at least for my use case, keeping track is rather difficult.
I did simply add them to independent pairs (with one stylistic set, that makes 290...), but that renders it rather complicated to re-work independent pairs that get set by Kern On when a model is rejected. Not sure whether splitting into Independent Pairs and Rejected Pairs makes sense, but at least for my use case, keeping track is rather difficult.
- Tim Ahrens
- Site Admin
- Posts: 437
- Joined: 11 Jul 2019
Re: Group-group-specific kerning rules
Good question. I am open to discussing this. Would you prefer to not kern maths operators against each other at all? What exactly is the reasoning? How about things like “C++”? Or “x += 1”? Or things like “>>” when it is used as a graphic pattern?
Which characters would you kern the maths operators against? In a way, we’d have to think through how the various maths operators are used, and some may be used differently from others. For example, it’s naive to assume that the plus sign will often be used in something like 2+3=5. I guess it’s much more likely to be used in things like “CANAL+” or “New size! +50% content!”. Also: Would comparison operators ever be used without space around it? I personally wouldn’t. Oh wait, maybe in combination with parentheses. Tricky.
So, if you have a convincing concept of what to kern before and after the various maths punctuation I’ll be happy to adjust the list of Unicode pairs.
Just so I understand correctly: You added maths punctuation against ech other as independent zero pairs, right?
Agreed, a special treatment of rejected would be useful, and it’s on my to-do list. Also, it might be interesting to automatically re-activate rejected models once it becomes possible again. Need to think that through a bit more.
Re: Group-group-specific kerning rules
Hello, apologies for me belated reply. I admit your questions stumped me and I don't quite know what to answer. I hadn't thought about this question enough and simply based my instinct not to kern them off the fact that I (like most others) make my maths operators tabular. So, instinctively, I wouldn't kern them (as would the people I talked to about this), but as you point out, this doesn't make practical sense. Thanks for pointing this out! I will get myself used to kerning them ;)