Normalise kerning to spacing?

[claegg]

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.

[SCarewe]

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.

[claegg]

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.

[Tim Ahrens]

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:

• 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]

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.

[claegg]

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.

[Tim Ahrens]

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.

[claegg]

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.

[SCarewe]

@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/

[claegg]

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