Consider UC and LC separately
Consider UC and LC separately
First off, this is an incredible tool and it's very exciting to follow!
I hope this is the place to give feedback and talk about issues. I have some qualms with a few of the decisions the engine is making. Don't ask me why exactly, but I space my caps identically to lowercase (|H| = |n = |b). Kern On doesn't agree with this, which is fine, but I have no way of voicing my disagreement to the engine. It deletes model pairs I set up for lowercase because my uppercase is "too tight", or vice versa. I would love to be able to consider UC and LC as seperate kerning fields, or rather let the engine know that I don't agree with it in thinking that my UC need generally be spaced more loosely than my LC. I hope what I wrote somewhat made sense (without wanting to start a discussion about spacing philosophies concerning LC/UC). Thank you!
I hope this is the place to give feedback and talk about issues. I have some qualms with a few of the decisions the engine is making. Don't ask me why exactly, but I space my caps identically to lowercase (|H| = |n = |b). Kern On doesn't agree with this, which is fine, but I have no way of voicing my disagreement to the engine. It deletes model pairs I set up for lowercase because my uppercase is "too tight", or vice versa. I would love to be able to consider UC and LC as seperate kerning fields, or rather let the engine know that I don't agree with it in thinking that my UC need generally be spaced more loosely than my LC. I hope what I wrote somewhat made sense (without wanting to start a discussion about spacing philosophies concerning LC/UC). Thank you!
- Tim Ahrens
- Site Admin
- Posts: 416
- Joined: 11 Jul 2019
Re: Consider UC and LC separately
Thanks for your feedback! The UC/LC question is one of the topics I will address in my more in-depth video soon but I’m glad you’re asking as it helps me formulate things more clearly.
First, I should explain that Kern On treats all UC letters as one big special spacing group internally. As you imply, most designers do space the UC a little looser than LC, so KO allows for that without the user having to set up the UC special spacing group explicitly.
When special spacing is applied, however, this does not mean the pairs have to be looser, it just means they are allowed to. When comparing pairs, special spacing acts as a sort of leeway: it widens the possible range on one side (depending on the difference of the two pairs’ special spacing values).
So, in a way, this somewhat separates UC and LC as separate fields, depending on the amount of your UC special spacing.
So, while Kern On allows UC to be spaced more loosely, it does not enforce this. If your UC is consistently spaced like your LC then Kern On will realize that there is not UC special spacing. So, what you do is supported, Kern On does not think UC needs to be looser. As a side note, KO will not allow UC to be spaced tighter than LC (negative special spacing is allowed for the manually-set groups but not for the internal UC group).
If Kern On removes a model because a UC pair is tighter than an LC pair then this means there must be a real mismatch even if you assume UC is not supposed to be looser than LC. It simply means the UC is literally tighter than the LC. If you disagree with a particular decision then it would be good to send me the font, then I can have a closer look.
First, I should explain that Kern On treats all UC letters as one big special spacing group internally. As you imply, most designers do space the UC a little looser than LC, so KO allows for that without the user having to set up the UC special spacing group explicitly.
When special spacing is applied, however, this does not mean the pairs have to be looser, it just means they are allowed to. When comparing pairs, special spacing acts as a sort of leeway: it widens the possible range on one side (depending on the difference of the two pairs’ special spacing values).
So, in a way, this somewhat separates UC and LC as separate fields, depending on the amount of your UC special spacing.
So, while Kern On allows UC to be spaced more loosely, it does not enforce this. If your UC is consistently spaced like your LC then Kern On will realize that there is not UC special spacing. So, what you do is supported, Kern On does not think UC needs to be looser. As a side note, KO will not allow UC to be spaced tighter than LC (negative special spacing is allowed for the manually-set groups but not for the internal UC group).
If Kern On removes a model because a UC pair is tighter than an LC pair then this means there must be a real mismatch even if you assume UC is not supposed to be looser than LC. It simply means the UC is literally tighter than the LC. If you disagree with a particular decision then it would be good to send me the font, then I can have a closer look.
Re: Consider UC and LC separately
Hi, many thanks for your detailed explanation. I have played around a lot more with Kern On and have not quite been able to understand at what point it disagrees with my spacing. For testing, I ran it on a font spaced with HT Letterspacer. Still, it tries to insert negative kerning kerning for on or positive kerning for OH and I can't use on and OH as models simultaneously. Anyhow, a different case, similar scneario: I am looking at kerning for my numbers, the default ones being porportional osf. The numbers are spaced a little bit looser (1| = 47, |H| = 41). Kern On tries to apply the spacing scale to that of the caps. See attached screenshots.
Maybe, to get it out of the way: I space caps with the same spacing as my LC because I want Hn to be the same as dn. A lot of the time, caps are spaced looser and then are kerned negatively against all of lowercase, which is an incredibly tedious process, so I kern all caps a lot tighter than is good for them among each other and then hardcode capital spacing directly into the kern feature (which, by the way, prevents Kern On from starting, I have to delete the extra code in kern first).
Maybe, to get it out of the way: I space caps with the same spacing as my LC because I want Hn to be the same as dn. A lot of the time, caps are spaced looser and then are kerned negatively against all of lowercase, which is an incredibly tedious process, so I kern all caps a lot tighter than is good for them among each other and then hardcode capital spacing directly into the kern feature (which, by the way, prevents Kern On from starting, I have to delete the extra code in kern first).
- Attachments
-
- 2021-04-26 00.05.25.jpg (56.26 KiB) Viewed 28350 times
-
- 2021-04-25 23.51.50.jpg (21.95 KiB) Viewed 28350 times
- Tim Ahrens
- Site Admin
- Posts: 416
- Joined: 11 Jul 2019
Re: Consider UC and LC separately
What you explain is a perfectly sensible approach, and it is supported by Kern On.
If you want UC-UC, UC-LC and LC-LC to be just as tightly spaced then let’s start with HH, Hn and dn as zero models. The straights have the same sidebearings (|H|, |n and d|). I agree, and KO agrees.
However, shouldn’t the O| be somewhat looser than the o|? What is the RSB of the P in your font? Isn’t it tighter than O|? Why is this so? Because it is “vertically smaller”, or “more tightly curved”, or “more pointy” than the O, one could say. If you compare P| to b|, why is P| tighter but not b|? (I assume b| = o|) Without seeing your whole font, I am making assumptions here but I hope you are getting the point. Generally speaking, the sidebearing of a shape needs to be smaller if the shape is “vertically smaller”, or “more tightly curved”, or “more pointy”, this is why o| should be tighter than O| while the straights |H and |n can be identical.
So, I hope the comparison of O|, P| and b| makes this clear. Of course, the bowl of the P is not identical to the b but I hope it makes sense.
If you want UC-UC, UC-LC and LC-LC to be just as tightly spaced then let’s start with HH, Hn and dn as zero models. The straights have the same sidebearings (|H|, |n and d|). I agree, and KO agrees.
However, shouldn’t the O| be somewhat looser than the o|? What is the RSB of the P in your font? Isn’t it tighter than O|? Why is this so? Because it is “vertically smaller”, or “more tightly curved”, or “more pointy” than the O, one could say. If you compare P| to b|, why is P| tighter but not b|? (I assume b| = o|) Without seeing your whole font, I am making assumptions here but I hope you are getting the point. Generally speaking, the sidebearing of a shape needs to be smaller if the shape is “vertically smaller”, or “more tightly curved”, or “more pointy”, this is why o| should be tighter than O| while the straights |H and |n can be identical.
So, I hope the comparison of O|, P| and b| makes this clear. Of course, the bowl of the P is not identical to the b but I hope it makes sense.
- Tim Ahrens
- Site Admin
- Posts: 416
- Joined: 11 Jul 2019
Re: Consider UC and LC separately
That’s also possible with the help of Kern On. You can space HH apart (but not Hn and dn), and KO will understand that the special spacing within the UC (i.e. in UC-UC pairs) is an independent value. So the intra-UC special spacing could be positive while the mixcase (i.e. UC-LC) special spacing is zero (this is the terminology I am using in my code)
For our upcoming JAF typeface, I am doing just that: The HH has a positive value, and many of the H-to-UC combinations have that same value but could be somewhat less. In the end, you will need a few more models, becaue the intra-UC is not simply added to each pair, but it’s definitely feasible.
There is a tricky question, however: If the UC-UC combinations have extra space via kerning, and the mixcase combinations don’t, how about the punctuation-UC combinations? If we heavily space out UC-UC but not the punctuation then the punctuation will be too tight in punctuation-UC-UC combinations. If we also make the punctuation-UC pairs significantly looser then e.g. something like (Had) will not be visually centred within the parentheses, so we can rule this out. So, I believe auto-spacing UC-UC is only possible if it is rather subtle, because we don’t know whether (H will be followed by LC, or is part of an all-caps setting.
- Tim Ahrens
- Site Admin
- Posts: 416
- Joined: 11 Jul 2019
Re: Consider UC and LC separately
Simple case: That’s what special spacing is for! Just give the figures a special spacing group (create a new one, I’d call it something like “prop osf” or “figures”). Make sure to assign the special spacing group to the right sides as well as the left sides. And, of course, don’t forget to set a model, e.g. 1H or 1n as a zero-model.
However, why are you including the extra spacing into the figures via spacing while you add it to the UC via hardcoded kerning? To me, it seems conceptually the same. Shouldn’t it be solved with the same technique?
Re: Consider UC and LC separately
Hi Tim, apologies for my belated reply. What you wrote made an immense amount of sense (unsurprisingly), I hadn't even realised that, of course, I could simply add the kerning I hardcode through Kern On. Thanks for that tip! I've now set up my file accordingly and it works fantastically. some issues here and there, like model .H contradicts model .n contradicts model n., but I've just made those exceptions for now. Thank you very much! I hope that, in the released (paid) version, it will be possible to not have the kerning groups be called KO_. Is it thinkable to allow the user to rename kerning groups on the fly through Kern On? Thank you!
Re: Consider UC and LC separately
Ah, one extra question. For some reason, it was impossible for me to have the SC considered seperately, apparently, they were too tight (h.sc h.sc too tight against HH). Since this is genuinely a field where it depends on the designer's taste as to how much extra spacing should be given to the SC, wouldn't it be sensible to truly consider them separately? Maybe I'm misunderstanding something again, but I couldn't quite figure it out. Now Kern On has written the final kerning and all my smallcaps have 20 kerning, which is somewhat unnecessary.
Re: Consider UC and LC separately
Okay, this is most definitely an unintended bug. I cannot make h.sc h.sc a model without contradicting HH, but I can make h.sc n.sc a model, which works fine, but then h.sc h.sc still gets -20 kerning and ignores the h.sc n.sc model. n.sc n.sc receives +31 kerning. They all have the same sidebearings, of course (I triple-checked my metrics keys). Can it be that the smallcap height or some other metrics aren't read properly? See attached screenshot.
Edit: Yes, it definitely is that. For testing, I changed the diagonal of the n.sc (just dragged the points between the stems up and down) et voilà, KO changed the kerning. This means that Kern On is also calculating space inside my n.sc because it thinks my SC are higher than I have drawn them. Is there some way of telling KO how high my SC are? Is KO maybe miscalculating my SC height due to looking at SC with accents?
Edit: Yes, it definitely is that. For testing, I changed the diagonal of the n.sc (just dragged the points between the stems up and down) et voilà, KO changed the kerning. This means that Kern On is also calculating space inside my n.sc because it thinks my SC are higher than I have drawn them. Is there some way of telling KO how high my SC are? Is KO maybe miscalculating my SC height due to looking at SC with accents?
- Attachments
-
- 2021-05-06 02.31.29.jpg (30 KiB) Viewed 28304 times
- Tim Ahrens
- Site Admin
- Posts: 416
- Joined: 11 Jul 2019
Re: Consider UC and LC separately
Looking at your screen shots above, in the extralight, your |H and |n are 120 whereas the n| is 115. This makes sense (and I do it the same way), as the n is curving inwards around the x-height.
However, when comparing .n and n. it is almost irrelevant what is going on “up there”, as the period does not “look upwards” that steeply. In other words, having .n and n. both with a zero value would be an inconsistency; n. would be tighter than .n – I hope that makes sense. Therefore I find it natural that in most sans serifs, n. needs positive kerning (or, alternatively, .n needs negative kerning). Maybe it becomes clearer if you play around with Glyphs’ distance measuring tool.
Re: Consider UC and LC separately
Yes, I figured as much. I just would have never considered negatively kerning .n or .H, but if KO wants to, alright. It makes sense, technically at least.
- Tim Ahrens
- Site Admin
- Posts: 416
- Joined: 11 Jul 2019
Re: Consider UC and LC separately
Can you explain why you would find this feature beneficial? Keep in mind that the names of the kerning groups will not end up in the exported fonts.
- Tim Ahrens
- Site Admin
- Posts: 416
- Joined: 11 Jul 2019
Re: Consider UC and LC separately
Can you try again with the latest version (0.9b17 as of now)? I think this is a bug I fixed.
If you are still experiencing this obviously wrong behaviour with 0.9b17 or later, would you mind sending me the file? Thanks!
Re: Consider UC and LC separately
I thought I had installed 0.9b17, apparently I hadn't. Thanks! Now, I at least don't run into the same issue with my h.sc n.sc as described above, but I now have the issue that, apparently, in my ExtraLight, h.sc h.sc is too loose in comparison to HH. To test, I spaced a file with HT Letterspacer and set my SC spacing to 1.1. This is pretty much exactly the relation I space manually. In the ExtraLight, this looks good to me, but KO doesn't agree.
So, in this example, I have |n = 111 and |h.sc| = 122. I would love to have the SC really spaced like that and not hardcode some extra kerning there, because SC will almost only be used among SC, not like hardcoding kerning for UC, which will mostly be used among SC. Is it possible to add some sort of factor into the spacing of the SC in comparison to UC? I would humbly suggest using the UC models for SC, but allowing for some sort of factor to space them more loosely, if desired. Would this be feasible and make sense? Thank you!
Edit: In my Black, I have |n = 51 and |h.sc| = 56, which works fine together, for some reason. |H| = 51, of course, with +20 kerning. Works fine. Why not in my ExtraLight?
So, in this example, I have |n = 111 and |h.sc| = 122. I would love to have the SC really spaced like that and not hardcode some extra kerning there, because SC will almost only be used among SC, not like hardcoding kerning for UC, which will mostly be used among SC. Is it possible to add some sort of factor into the spacing of the SC in comparison to UC? I would humbly suggest using the UC models for SC, but allowing for some sort of factor to space them more loosely, if desired. Would this be feasible and make sense? Thank you!
Edit: In my Black, I have |n = 51 and |h.sc| = 56, which works fine together, for some reason. |H| = 51, of course, with +20 kerning. Works fine. Why not in my ExtraLight?
Re: Consider UC and LC separately
Tim Ahrens wrote:
> Can you explain why you would find this feature beneficial? Keep in mind
> that the names of the kerning groups will not end up in the exported fonts.
That's probably just my eye not used to it and my desire to have clean kerning group names. I imagine that if, after Kern On has completed kerning, I want to make some really detailed changes here and there, it would be a lot more handy to have "natural" names.
Sorry, I can't figure out how to quote properly for some reason.
> Can you explain why you would find this feature beneficial? Keep in mind
> that the names of the kerning groups will not end up in the exported fonts.
That's probably just my eye not used to it and my desire to have clean kerning group names. I imagine that if, after Kern On has completed kerning, I want to make some really detailed changes here and there, it would be a lot more handy to have "natural" names.
Sorry, I can't figure out how to quote properly for some reason.
- Tim Ahrens
- Site Admin
- Posts: 416
- Joined: 11 Jul 2019
Re: Consider UC and LC separately
Regarding the SC spacing, I am not sure I understand how exactly they are spaced, without seeing the file.
Have you set up special spacing for the SC? That will not apply a factor (as you suggest) but something similar to an added spacing (but in detail, it is a bit more complex).
Have you set up special spacing for the SC? That will not apply a factor (as you suggest) but something similar to an added spacing (but in detail, it is a bit more complex).
- Tim Ahrens
- Site Admin
- Posts: 416
- Joined: 11 Jul 2019
Re: Consider UC and LC separately
The idea is that you don’t need to make adjustments after Kern On has completed the kerning. Instead, if you spot any changes that need to be made, you can set additional models. Working on the source, so to speak. Wouldn’t this work for you?
Sorry, I am using this stone-age forum software, it’s not very convenient. It seems to be working just well enough for basic conversations. To quote, you can click the button on the top right but careful, this will erase your draft, I believe.
Re: Consider UC and LC separately
I am very confused. I swear on Speedpunk that I haven't changed a thing regarding SC being classified as Special spacing, smallcaps, but after restarting Glyphs and KO, I don't run into this issue anymore. I can set h.sc h.sc and HH as models in my ExtraLight and everything works. Sorry for the fuss, but apparently, this has just resolved itself. Very odd, but great!
Re: Consider UC and LC separately
Hello again, I'm very sorry to constantly be reviving this topic. I have started to play around with kerning numbers. Kern On decides that my numbers are too loose and positively kerns almost all of them (with disastrous results). So I thought it might be useful to set up a special kerning group for numbers, which I did (LF 0–9, just called numbers for now). I started setting up models, but then KO told me that everything was inconsistent, throwing out stuff like HH, HO, no, etc. Maybe I'm misunderstanding the point of these special spacing groups, but in any case, it doesn't work as I hoped it would. Is there an explanation as to why/how I misused this feature? I'm happy to send you the glyphs file if that helps.
- Tim Ahrens
- Site Admin
- Posts: 416
- Joined: 11 Jul 2019
Re: Consider UC and LC separately
Sorry, yes, my mistake. KO decides they are too tight in my Black and too loose in my ExtraLight. I removed all the number models and sent you the font file. Thanks a lot!
Re: Consider UC and LC separately
Hello again. Sorry, but there is definitely something very wrong with KO's interpretation of smallcap spacing. I have tried every spacing under the sun and found that only if I set |h.sc|=|n, KO doesn't complain. I have now spaced my SC exactly like my LC, which looks terrible, but only like that, KO leaves my models in peace. To save time, I tried different factors with HT Letterspacer (all the way from 1.2, which looks best in my eyes, to 1), but only at 1 (so the same spacing factor as my LC) does KO not rip my models apart. What is KO's (intended) tolerance for spacing differentiation between the different spacing groups of UC/LC/SC?
- Tim Ahrens
- Site Admin
- Posts: 416
- Joined: 11 Jul 2019
Re: Consider UC and LC separately
Sorry, I only just had a look at the file you sent (on 17 May). I cannot confirm the problems you are describing, the numbers can be set as desired, e.g. one-three or one-one as zero model, without creating contradictions. Also, the small caps can be set as desired, without any warnings.
Which KO version are you using?
Also, keep in mind that special spacing does not make the group entirely independent. The group can be either looser than the standard kerning or tighter. So, you cannot entirely eliminate comparisons with the letter-letter model pairs.
Which KO version are you using?
Also, keep in mind that special spacing does not make the group entirely independent. The group can be either looser than the standard kerning or tighter. So, you cannot entirely eliminate comparisons with the letter-letter model pairs.
- colinmford
- Posts: 7
- Joined: 07 Jul 2021
Re: Consider UC and LC separately
I was going to make a new post about this topic but I might just chime in here:
I understand fully the goal of Kern On is to make everything consistent. However, I found that I often was receiving errors like "Removing model XH because it is tighter than rt". To me, cases just need to be considered differently, and even when I set up special spacing groups as granular as I was comfortable with, Kern On was still finding pairs from one case contradicting another.
So as an experiment I forced Kern On to only look at the UC and the LC separately by manipulating the pair_frequencies.txt file, and I've been getting much better results. The consistency between cases might not be "perfect" in the eyes of Kern On, but the consistency within each case is better, and I get much fewer model conflicts which makes the kerning process a lot quicker.
I'm not sure how it would be done — but I think I would find it useful if within Kern On I could completely quarantine one case from another; for it to somehow have different models for sections of the character set.
I understand fully the goal of Kern On is to make everything consistent. However, I found that I often was receiving errors like "Removing model XH because it is tighter than rt". To me, cases just need to be considered differently, and even when I set up special spacing groups as granular as I was comfortable with, Kern On was still finding pairs from one case contradicting another.
So as an experiment I forced Kern On to only look at the UC and the LC separately by manipulating the pair_frequencies.txt file, and I've been getting much better results. The consistency between cases might not be "perfect" in the eyes of Kern On, but the consistency within each case is better, and I get much fewer model conflicts which makes the kerning process a lot quicker.
I'm not sure how it would be done — but I think I would find it useful if within Kern On I could completely quarantine one case from another; for it to somehow have different models for sections of the character set.
- Tim Ahrens
- Site Admin
- Posts: 416
- Joined: 11 Jul 2019
Re: Consider UC and LC separately
Thanks for your feedback, Colin!
About the “Removing model XH because it is tighter than rt”: It’s tricky to define which cases of inconsistency (according to Kern On’s analysis of the shapes) to let slip through or not. Throughout the development of Kern On, I was faced with the question of how flexible to make it, or in how far to make it enforce consistency. I could make it more flexible than now, i.e. accept models that it considers inconsistent (conversely, I could make it stricter as well). In the end, I can only hope that the users will develop trust in Kern On, and accept the occasional adjustment of sidebearings.
That said, I will implement “bubbles”, which will allow to have independent Kern On model-auto systems. If you put UC and LC in separate bubbles that would mean UC-to-LC pairs would not be kerned at all so it may not help in your case.
Kern On does consider LC and UC somewhat independently in that UC can be looser than UC, without any limits. The only thing that will be rejected if UC is tighter than LC. It would be interesting to see your XH vs rt example, and to take a few measurements. Sometimes this can be quite revealing (and surprising).
About the “Removing model XH because it is tighter than rt”: It’s tricky to define which cases of inconsistency (according to Kern On’s analysis of the shapes) to let slip through or not. Throughout the development of Kern On, I was faced with the question of how flexible to make it, or in how far to make it enforce consistency. I could make it more flexible than now, i.e. accept models that it considers inconsistent (conversely, I could make it stricter as well). In the end, I can only hope that the users will develop trust in Kern On, and accept the occasional adjustment of sidebearings.
That said, I will implement “bubbles”, which will allow to have independent Kern On model-auto systems. If you put UC and LC in separate bubbles that would mean UC-to-LC pairs would not be kerned at all so it may not help in your case.
Kern On does consider LC and UC somewhat independently in that UC can be looser than UC, without any limits. The only thing that will be rejected if UC is tighter than LC. It would be interesting to see your XH vs rt example, and to take a few measurements. Sometimes this can be quite revealing (and surprising).
- Tim Ahrens
- Site Admin
- Posts: 416
- Joined: 11 Jul 2019
Re: Consider UC and LC separately
I think I know what you mean: when a model is removed because of a contradiction that involves different special spacings, and you wonder why it didn’t simply adjust the special spacing(s) accordingly to resolve the mismatch.colinmford wrote: ↑07 Jul 2021 even when I set up special spacing groups as granular as I was comfortable with, Kern On was still finding pairs from one case contradicting another.
Recently I improved (I hope) the way Kern On handles these cases when it doesn’t manage to get all models to work together, and when special-spaced pairs are involved in the mismatches. This can be a rather convoluted situation, if one model-model comparison says special spacing A must be greater than B, and another comparison says B must be greater than A. Especially if more than two special spacing values are involved we may have complex circular dependencies and it’s difficult to decide which model to remove. I hope the next release will reduce the cases when you find surprising model removals if they involve special spacing.
- colinmford
- Posts: 7
- Joined: 07 Jul 2021
Re: Consider UC and LC separately
Thanks on both accounts, Tim! I'll look out for the update. Do you have a sense when that might be released?
- Tim Ahrens
- Site Admin
- Posts: 416
- Joined: 11 Jul 2019
Re: Consider UC and LC separately
I just released an update (see https://kern-on.com/update/) that hopefully makes it easier to handle special spacing, i.e. it better applies the priorities.
Note that clicking the “Try again” button, or setting a previously removed model again (which has the same effect) gives the pair(s) a higher internal priority and KO tries to resolve mismatches by removing a standard-priority pair instead.
Note that clicking the “Try again” button, or setting a previously removed model again (which has the same effect) gives the pair(s) a higher internal priority and KO tries to resolve mismatches by removing a standard-priority pair instead.