Normalise kerning to spacing?
Normalise kerning to spacing?
I can see that Kern On likes to consistently to consistently kern or space certain glyphs. All fine and good, but it would be real swell if these consistent kerning values could be moved into spacing instead, automatically of course.
I’ve found that proceedings move along easier with Kern On are not given too many exceptions to work with. Kern On seems to want to delete a lot of existing models when I try to ‘enforce’ my spacing in say, the small-caps.
I’ve found that proceedings move along easier with Kern On are not given too many exceptions to work with. Kern On seems to want to delete a lot of existing models when I try to ‘enforce’ my spacing in say, the small-caps.
Re: Normalise kerning to spacing?
Yes, expanding Kern On into a spacing tool is an idea that has been bounced around here a few times. Definitely a big interest in it! Personally, I would prefer it as a standalone tool, to use before moving to Kern On. How the model logic should work is an important question, but I guess those might become obsolete when spacing with a Kern On tool in the first place.
Re: Normalise kerning to spacing?
It would make no sense to separate the automagic spacing from the automagic kerning. I should be possible to make a monolithic system that takes care of both in one go. Let the user set some of the sidebearings and have the system create a system of exceptions (and exceptions to the exceptions) and that way build up the complete spacing and kerning.
The TeX system did similar when the line break system was built – exceptions to the exceptions, and ‘badness’ points to possible outcomes would rank the least bad solution.
The TeX system did similar when the line break system was built – exceptions to the exceptions, and ‘badness’ points to possible outcomes would rank the least bad solution.
- Tim Ahrens
- Site Admin
- Posts: 447
- Joined: 11 Jul 2019
Re: Normalise kerning to spacing?
Yes, this has been an idea of mine for a long time, and I have been thinking about it again for the last few weeks.
This is how it could work:
This is how it could work:
- The user sets the sidebearing of a particular glyph to “auto”. Plus, the special spacing, of course. I suspect that it is mostly the special-spaced glyphs that the user wants to be auto-spaced.
Next, either of these two things could happen:
- Kern On determines the auto-sidebearing that leads to the fewest non-zero pairs. That’s the geeky technical approach: we want to optimize the kerning in terms of data size. Not sure whether this leads to sidebearing (and, therefore, non-zero pairs) that feel “natural” to the user. Also, changing the sidebearing and adjusting all kerning pairs accordingly is not without any impact, if we consider the sides of paragraphs, of text centered on buttons, or glyphs next to the space character.
- The user is allowed to set model pairs that include auto glyph-sides. In that case, we’d be talking about “spacing models”, in which the user does not express what they consider the correct amount of space between glyphs but what they wish the kerning value to be. In practice, these would mostly be zero-models: if # is auto-spaced then the spacing model “#h = zero” would be used to determine the RSB of the #.
It could be a neat feature to simply define “neutral” glyph-sides that should never be kerned, which probably works best in sans-serif designs, where the H, the left side of the h, and the right side of the d could be considered as neutral, and any kerning to these glyph-sides must be a spacing mistake. In seriffed designs, it’s usually not that easy, though.
- Tim Ahrens
- Site Admin
- Posts: 447
- Joined: 11 Jul 2019
Re: Normalise kerning to spacing?
Btw, what exactly do you mean when you say “exceptions”? I am trying to avoid the term unless I am really taking about kerning exceptions in the traditional sense, i.e. glyph-glyph pairs that override class-class-kerning pairs.
Re: Normalise kerning to spacing?
As an example of working with exceptions, imagine an I, and then set the spacing between two Is. That could be the starting point from where all deviations are ‘exceptions’, eg. the O against the I: IIOII. The sidebearing from I has to be made smaller before you apply it to the O. But what about IOOI? Now you have to make an exception for two Os next to each other. In a seriffed font you either have to kern the IOI combination, or space the OO combination. Now you should have a system of exceptions to exceptions, and if you change the spacing on the root glyph – the I – then the changes on that one will cascade through the entire font.
The advantage is that the designer only sets the absolute minimum of values to make the spacing/kerning work. Subsequent changes anywhere in the branches of exceptions would then re-do all the values from the change and out to the tip of that branch.
The advantage is that the designer only sets the absolute minimum of values to make the spacing/kerning work. Subsequent changes anywhere in the branches of exceptions would then re-do all the values from the change and out to the tip of that branch.
- Tim Ahrens
- Site Admin
- Posts: 447
- Joined: 11 Jul 2019
Re: Normalise kerning to spacing?
Sounds very interesting but isn’t that something that can be achieved with the currently available tools? If you want to adjust the spacing of the root glyph and then everything else, wouldn’t you simply select all the letters and use the Transform Metrics tool? As far as I understand that would heave the same effect.
Re: Normalise kerning to spacing?
Well yes and no. The built-in functionality of Glyphs can link and transform metrics from other glyphs, but I wouldn’t try to make it all balance on one key glyph. That would require a more advanced system to handle it all in one go, and to make sure nothing breaks. The system in Glyphs is also (AFAIK) limited to one transformation modifier, eg. "=n*0.15" or "=n+25" but not both which would get closer to balancing everything on one glyph.
Re: Normalise kerning to spacing?
@claegg Are you aware of the HT Letterspacer? I have been using it for quite some time now and it works very well with Kern On. Of course, the principles behind the Letterspacer are somewhat simpler than those of Kern On, but it still works very well. I made a quick graphic interface for setting up the parameters: https://github.com/eweracs/glyphs-scrip ... ualiser.py
Just as a pointer, the two tools that I have been dreaming of for some time is BlackFoundry's two spacing and kerning tools. A commercial release has been delayed for years, sadly: https://black-foundry.com/blog/blackspacer-blackkerner/
Just as a pointer, the two tools that I have been dreaming of for some time is BlackFoundry's two spacing and kerning tools. A commercial release has been delayed for years, sadly: https://black-foundry.com/blog/blackspacer-blackkerner/
Re: Normalise kerning to spacing?
Thank you. I have never used HT Letterspacer but have put it in the list of things to try in the future.
Have any of you tried BubbleKern? https://github.com/Tosche/BubbleKern
Have any of you tried BubbleKern? https://github.com/Tosche/BubbleKern
- Tim Ahrens
- Site Admin
- Posts: 447
- Joined: 11 Jul 2019
Re: Normalise kerning to spacing?
It’s been a while but I made some progress with some sort of autospacing. Let’s use this thread, I think “Normalise kerning to spacing” is a very good description of what we are talking about.
As I wrote above, there are several possible approaches, each with their pros and cons.
What I have tried:
(1) Auto-spacing by minimising the number of non-zero kerning pairs. Assuming we have enough partners (i.e. pairs) per glyph-side, we could hope that the “neutral” sides among the partners will win, as minimising the number of non-zero pairs is a bit like a median (as opposed to average) logic.
Unfortunately, this does not work: The typical partners for each glyph are not equivalent enough. For example, in my experiments, the LSB of a V was auto-spaced more loosely than the RSB. Why is that? Because the V will usually be preceded by UC but it will be followed by UC and LC. Pairs such as Vo will “bump down” the RSB so much as to create asymmetrical sidebearings of the V (even if the shape was perfectly symmetrical). So, that’s not acceptable. The only solution would be not to use natural pairs but something synthetic, something that guarantees the same outcome for identical shapes (which leads to (4) below).
(2) Auto-spacing by looking at pure sidebearing shapes without partner glyphs, i.e. not using KO’s pair-comparison and kerning mechanism. As always, consistency is all KO cares about (almost the only concept it knows), so we have to compare the to-be-autospaced glyph-side to all (?) the others and do the median thing again. One problem is to adjust the KO engine so as to be able to compare shapes without a partner. So far, the results have not been good enough. In contrast to (1), I have not given up yet, it’s still in my code, commented-out, so to peak.
(3) Some sort of inconsistency warning mechanism, purely looking at kerning values: If a certain glyph-side is kerned tighter than another one for all shared partners then the spacing must be inconsistent. E.g. if (A tighter than [A, (B tighter than [B, and for all second glyphs, we can conclude that the RSB of the \( must be decreased, or the RSB of the \[ increased. The necessary correction would be the least different pair comparison. This approach is 100% safe and undeniable but it’s not very powerful. It only works with extremely similar shapes.
(4) What is available now (since version 1.15): Autospacing via “zero partners”. In the sidebearing fields of the Kern On window, you can enter one or several glyph names (slash separated) that should not have kerning (i.e. zero value) against this glyph side. Kern On will adjust the sidebearing so that the kerning with the given partner(s) becomes zero. Of course, this may not be possible for all partners. You can specify a partner glyph several times so as to increase its priority. For example, specifying /H/H/d for the LSB of the two will lead to zero kerning for H2 and, if possible, also zero kerning for d2. Autospacing via “zero partners” usually works well for sans-serifs, where you would typically specify /H/d for the autospaced LSB and /H/h for the RSB.
Note:
• You can autospace several glyphs at the same time (i.e. with several glyphs selected).
• You cannot autospace glyph sides that appear in models.
• You can specify characters instead of glyph names but they also need to be separated by slash, e.g. /H/d/| (the last one is a bar).
• You can combine this autospacing with the “autokern from” feature. In other words, in a typical sans-serif, you can almost completely autospace the italics based on the upright (after carefully setting the standard flat sides manually).
• Right now, this autospacing is a one-off action, the sidebearings don’t “remember” their setting, and they don’t auto-update. I am planning to implement that, though.
In a way, this is the least “automatic” of the approaches but at it gives predicable results, and enough control to the user.
———————
I have been using zero partners in a real project of mine and it seems rather useful.
Any comments?
As I wrote above, there are several possible approaches, each with their pros and cons.
What I have tried:
(1) Auto-spacing by minimising the number of non-zero kerning pairs. Assuming we have enough partners (i.e. pairs) per glyph-side, we could hope that the “neutral” sides among the partners will win, as minimising the number of non-zero pairs is a bit like a median (as opposed to average) logic.
Unfortunately, this does not work: The typical partners for each glyph are not equivalent enough. For example, in my experiments, the LSB of a V was auto-spaced more loosely than the RSB. Why is that? Because the V will usually be preceded by UC but it will be followed by UC and LC. Pairs such as Vo will “bump down” the RSB so much as to create asymmetrical sidebearings of the V (even if the shape was perfectly symmetrical). So, that’s not acceptable. The only solution would be not to use natural pairs but something synthetic, something that guarantees the same outcome for identical shapes (which leads to (4) below).
(2) Auto-spacing by looking at pure sidebearing shapes without partner glyphs, i.e. not using KO’s pair-comparison and kerning mechanism. As always, consistency is all KO cares about (almost the only concept it knows), so we have to compare the to-be-autospaced glyph-side to all (?) the others and do the median thing again. One problem is to adjust the KO engine so as to be able to compare shapes without a partner. So far, the results have not been good enough. In contrast to (1), I have not given up yet, it’s still in my code, commented-out, so to peak.
(3) Some sort of inconsistency warning mechanism, purely looking at kerning values: If a certain glyph-side is kerned tighter than another one for all shared partners then the spacing must be inconsistent. E.g. if (A tighter than [A, (B tighter than [B, and for all second glyphs, we can conclude that the RSB of the \( must be decreased, or the RSB of the \[ increased. The necessary correction would be the least different pair comparison. This approach is 100% safe and undeniable but it’s not very powerful. It only works with extremely similar shapes.
(4) What is available now (since version 1.15): Autospacing via “zero partners”. In the sidebearing fields of the Kern On window, you can enter one or several glyph names (slash separated) that should not have kerning (i.e. zero value) against this glyph side. Kern On will adjust the sidebearing so that the kerning with the given partner(s) becomes zero. Of course, this may not be possible for all partners. You can specify a partner glyph several times so as to increase its priority. For example, specifying /H/H/d for the LSB of the two will lead to zero kerning for H2 and, if possible, also zero kerning for d2. Autospacing via “zero partners” usually works well for sans-serifs, where you would typically specify /H/d for the autospaced LSB and /H/h for the RSB.
Note:
• You can autospace several glyphs at the same time (i.e. with several glyphs selected).
• You cannot autospace glyph sides that appear in models.
• You can specify characters instead of glyph names but they also need to be separated by slash, e.g. /H/d/| (the last one is a bar).
• You can combine this autospacing with the “autokern from” feature. In other words, in a typical sans-serif, you can almost completely autospace the italics based on the upright (after carefully setting the standard flat sides manually).
• Right now, this autospacing is a one-off action, the sidebearings don’t “remember” their setting, and they don’t auto-update. I am planning to implement that, though.
In a way, this is the least “automatic” of the approaches but at it gives predicable results, and enough control to the user.
———————
I have been using zero partners in a real project of mine and it seems rather useful.
Any comments?
Re: Normalise kerning to spacing?
Tim,
Can you share an small screencast to see how to use autospacing?
Thanks
Can you share an small screencast to see how to use autospacing?
Thanks
- Tim Ahrens
- Site Admin
- Posts: 447
- Joined: 11 Jul 2019
Re: Normalise kerning to spacing?
Yes, I will record a video soon!
Re: Normalise kerning to spacing?
Tim Ahrens wrote:
> Yes, I will record a video soon!
Great!
> Yes, I will record a video soon!
Great!
Re: Normalise kerning to spacing?
>Autospacing via “zero partners”. In the sidebearing fields of
>the Kern On window, you can enter one or several glyph names
>(slash separated) that should not have kerning (i.e. zero value)
>against this glyph side. Kern On will adjust the sidebearing so
>that the kerning with the given partner(s) becomes zero.
I believe I have 1.15 installed (how can I check?), but am not seeing where to apply these instructions. What do you mean by ‘sidebearing fields of the Kern On window’?
Can you post a screenshot of what you mean, so I can confirm that I am seeing the same options in the KO window?
>the Kern On window, you can enter one or several glyph names
>(slash separated) that should not have kerning (i.e. zero value)
>against this glyph side. Kern On will adjust the sidebearing so
>that the kerning with the given partner(s) becomes zero.
I believe I have 1.15 installed (how can I check?), but am not seeing where to apply these instructions. What do you mean by ‘sidebearing fields of the Kern On window’?
Can you post a screenshot of what you mean, so I can confirm that I am seeing the same options in the KO window?
- Tim Ahrens
- Site Admin
- Posts: 447
- Joined: 11 Jul 2019
Re: Normalise kerning to spacing?
This is an example: Entering “/H/d” as the LSB of the three will adjust the LSB so that H-three and d-three have zero kerning. At the moment, this is temporary, the “/H/d” will disappear. I am planning to implement something permanent, though.
Re: Normalise kerning to spacing?
Thanks, Tim. I will experiment and try to make sense of what this does.
Re: Normalise kerning to spacing?
Well, this is pretty impressive. I spent the past few days manually re-spacing a new sans serif Cherokee design, and today used Kern On’s new feature to auto-space it for comparison, using my sidebearings of the Ꮋ (mi) syllable as a reference. What I found was that Kern On wanted to make the sidebearings of straight sided glyphs such as Ꭰ and Ꮊ tighter or looser than those of Ꮋ, so I had to adjust the latter to force the auto-spacing to get the straight vertical sidebearings close to where I wanted them, and then adjust back after the autospacing. I am hoping that this won’t confuse Kern On during the actual kerning.
https://twitter.com/TiroTypeworks/statu ... 5316608002
https://twitter.com/TiroTypeworks/statu ... 5316608002