Approaching Kerning Groups or Classes

Josh Nychuk

I'm looking for some advice on how to approach defining kerning groups or classes as they are referred to in various software.

Perhaps the most obvious group would include the uppercase letter A and all uppercase A with diacritics. This format would follow for any other letter, upper or lowercase.

I'm curious does anyone create groups based on similar side-bearing values, or similar shaped letterforms, or is that impractical? 

Bhikkhu Pesala

All of the accented A glyphs can be in the same class. One can combine letters like V and W in he same class, along wiht Ŵ, Ẅ, etc., but in some fonts, V and W have different shapes and don't fit well together. These two screen shots show the different Autogenerated kerning values for VA and WA Small Capitals.





I find that lowercase à ǎ ã and ä need to be in a different class to a, due to kerning pairs with T V W and Y. 

This is a screen shot from the Kerning Class Manager in FontCreator 10.1. O, Ó, Ò, Ö, etc., can be kerned left or right, but Ohorn combinations should only be the second glyph of a kerning pair. I use a naming convention that reminds me how to use the classes. 



FontCreator can generate kerning classes automatically, but I prefer to do it manually to retain full control. It has taken many iterations to arrive at a set of classes that I am happy with, but the kerning classes can now be imported into all of my fonts. 

Ray Larabie

I make left and right groups for glyphs with identical or very similar sides. For example: "A_left" includes all Æ glyphs, Delta, Lambda and Æ. "A_right" same as left but with Alphatonos and no Æ.

I name them left and right because that makes more sense to me but it's opposite; kerns for the left side of a glyph are right kerns and vice versa.

I put a few glyphs such as S into groups that have both left and right kerns. Not many of those.

I tend to push my luck as far as similarity goes. If it's not working, I'll kick that glyph out of the group and kern it on its own. Let's say I have a modular, squarish sans and the B and D are pretty close. I'll throw both of those into the O_right group. If it works, great. If I run into problems, I'll kick it out.

With Greek and Cyrillic, I have fun economizing groups. Sometimes I need to kern Cyrillic with letters that would never appear in Cyrillic based languages because they share a kerning parent with one side of a Greek letter. It's unnecessary to take it that far but I get a kick out of it when I'm kerning and they all sync up.

As for accent collisions, I do them last. If there are collisions, I kick them out of the group, copy/paste the kerning and modify all the pairs as needed.

Andreas Stötzner

> I make left and right groups for glyphs with identical or very similar sides. For example: "A_left" includes all Æ glyphs, Delta, Lambda and Æ. "A_right" same as left but with Alphatonos and no Æ.

Is it useful to group letters across writing systems? That shall multiply the amount of resulting pairs considerably. But in real texts, hardly any Latin v or e comes after a Greek Lambda …

Jens Kutilek

I tend to make ‘conceptual’ kerning classes for some groups of glyphs which are not identical in shape, and then see how far they hold up:

• quote-like glyphs (quotesingle minute quotedbl quotedblleft quotedblright quoteleft quoteright second uni2034 uni2057 degree)
• superscript glyphs (asterisk onesuperior ordfeminine ordmasculine threesuperior twosuperior uni2070 uni2074 uni2075 uni2076 uni2077 uni2078 uni2079 uni207A uni207B uni207C uni207D uni207E uni207F)
• subscript glyphs (uni2080 uni2081 uni2082 uni2083 uni2084 uni2085 uni2086 uni2087 uni2088 uni2089 uni208A uni208B uni208C uni208D uni208E)

I kern these against letters and punctuation.

Kent Lew

Is it useful to group letters across writing systems?

From a design perspective, it can be useful, in order to simplify the synchronization of values.

But from a production perspective, it can be valuable to have these split, for various reasons — e.g., to prevent enumeration of exceptions across writing systems, which just adds bloat (as Andreas alludes to).

Different designers undoubtedly have different strategies for managing these conflicting paradigms.

Ray Larabie

But in real texts, hardly any Latin v or e comes after a Greek Lambda …

If I add Lambda, Delta, Alpha and Cyrillic A to the A group, I've added zero kerning pairs. Sure, I'll never need to kern Lambda against v* but I've saved all those other kerns. Without adding a single pair, I've already kerned those 4 glyphs against hyphens, rounds, quotes and reduced the possibility of error or omission to zero. How does reducing the number of required pairs add bloat?

* Except in a Futura-ish typeface where ν looks identical to v, therefore v is the parent.

Kent Lew

In general, Ray is right. Adding Greek and Cyrillic glyphs to Latin classes adds very little (but not quite nothing) to the {kern} GPOS table.

The bloat only occurs if there is a class-glyph or glyph-class exception pair and the class has to be enumerated. In which case, that exception pair, which appears as one pair from a design standpoint, becomes several pairs from a font compilation standpoint.

If there are no exception pairs involving the multi-script class, then there is no bloat.

Georg Seifert

Or one could filter the flattening to not include pairs between different scripts. 

Kent Lew

Yes, ideally any splitting and filtering is handled as a pre-processing routine during compilation, leaving lumped classes intact in the master source for future design management and development.

Josh Nychuk

Thanks @Bhikkhu Pesala, @Ray Larabie and @Jens Kutilek for sharing your process and opinions. I've found it very helpful in thinking about kerning groups and confirming some suspicions that groups can be based on similar forms or side-bearings.

I understand that this process evolves over time to suit the individuals needs and the context of the typeface, so it's a good reminder to think about future development @Kent Lew

FontCreator was mentioned as software with auto-generated groups. I'm working in MetricsMachine for the first time and see that it is capable of auto-generating groups. I'm going to try this out today but if anyone would like to share any experiences working with this feature that would be great too. Thanks again for the help.