Kerning when making a font

Joon Park

Should I create kerning features + classes for every glyphs? or only for language based glyphs?
Also should I work on kerning between different language glyphs? (ie. latin and cyrillic or/and greek) 

Thomas Phinney

1) For all glyphs that interact with each other. For example, dashes and parentheses often need kerning. The fact that they are not specific to a language is not important.  A glyph that is likely to be offset or separated from other glyphs is less important. But (for example) I kern the trademark symbol against preceding glyphs.

2)  It is not very useful/important. Personally, I make classes that span languagesystems, so I end up doing this anyway. But it is a side effect of my workflow, not a goal.

James Puckett

Kern all Latin letter pairs. Proper nouns often break any rules that can be drawn from dictionaries.

Michael Vokits

James Puckett said:

Kern all Latin letter pairs. Proper nouns often break any rules that can be drawn from dictionaries.

+1. Not literally having a value for every pair (why kern two straights in succession, such as “ll” or “Ih”?), but you need to consider every pair. This also means UC and lc in every combination if you want CamelCase jargon like openType ClearType PowerPoint BullShit iEverything to look good, or speak kiSwahili at McDonald’s. Also kern dots and dashes and all other glyphs likely to occur next to letters.

Yes, it’s a ton of boring work, but it’s also necessary. Fortunately, kerning classes make it a lot easier: @O could easily contain /O and /Q and variants thereof, @o /o /e and others. (This all depends on your design; sometimes /V and /W have identical sides, sometimes they don’t.) I like to put every alphabetic glyph into precisely one class, even if it be a singleton — OpenType complains less (all pairs will be accessible, no specific kerning after class kerning, and so forth). Just work alphabetically through all pairs, from “AA” to “zz” just to be thorough. (Err, “AA” to “z,”)

Georg Seifert

You can use classes that span multiple scripts. But don't add specific kerning between scripts. 
About for the ll (lowercase L) and lk: if those need kerning, your spacing is not right. So don't take 'every combination' too literally. If you spacing is good, most letters should work without kerning. More importantly: don't forget pairs like f), f” and „j.

Christian Thalmann

Georg Seifert said:

About for the ll (lowercase L) and lk: if those need kerning, your spacing is not right.

I was going to object, but then found out I could remove the need to kern /l/l by making the right sidebearing of /l larger. Thanks for the insight!

Joon Park

Michael Vokits said:

 I like to put every alphabetic glyph into precisely one class, even if it be a singleton

Is there specific advantage of doing this? Also I only know a way to create (conveniently) through "generate kern features" in FL after doing classes and old style tables. 

Michael Vokits

Joon Park said:

Michael Vokits said:

 I like to put every alphabetic glyph into precisely one class, even if it be a singleton

Is there specific advantage of doing this? Also I only know a way to create (conveniently) through "generate kern features" in FL after doing classes and old style tables. 

“OpenType complains less (all pairs will be accessible, no specific kerning after class kerning, and so forth).”

Michael Vokits

Georg Seifert said:

About for the ll (lowercase L) and lk: if those need kerning, your spacing is not right. So don't take 'every combination' too literally. If you spacing is good, most letters should work without kerning.

Indeed, but it also depends on your design. You don’t have to be mechanical and form /k slavishly on /l – they could have differing serifs. Sometimes it’s fun to have sequences of the same letter use (perhaps widely) differing glyphs.

Joon Park

Michael Vokits said:

Joon Park said:

Michael Vokits said:

 I like to put every alphabetic glyph into precisely one class, even if it be a singleton

Is there specific advantage of doing this? Also I only know a way to create (conveniently) through "generate kern features" in FL after doing classes and old style tables. 

“OpenType complains less (all pairs will be accessible, no specific kerning after class kerning, and so forth).”

Could you clarify what you mean by this? (I am pretty new to this)
I assume you meant opentype kern feature isn't restricted as the kern table so technically I can have all pairs. But not sure what you mean by having every glyphs into one class. Even if a glyph doesn't have any other glyphs to pair into class, you would still make a class for a single glyph?

Mark Simonson

You can have classes that contain only a single glyph. And you can put all glyphs into classes, even if it means some of them end up being the only member of a class. You don't have to, and it won't affect how the font works, but you can do these things if you want to for some reason.

And, really, just forget about the kern table. The only thing you need in modern fonts is the kern feature. The only good reason for including the kern table is for compatibility with ancient software. Any modern software that depends on it is doing it wrong.

Joon Park

Mark Simonson said:

You can have classes that contain only a single glyph. And you can put all glyphs into classes, even if it means some of them end up being the only member of a class. You don't have to, and it won't affect how the font works, but you can do these things if you want to for some reason.

And, really, just forget about the kern table. The only thing you need in modern fonts is the kern feature. The only good reason for including the kern table is for compatibility with ancient software. Any modern software that depends on it is doing it wrong.

Hmm I only thought about doing it because FL has generate function for kern feature once I'm done fiddling with kern table. Do you recommend ignoring that and just learn coding for opentype kern?

Mark Simonson

It's a little confusing with FL.

Its kerning editor was designed back when the kern table was all there was. When the OpenType kern feature became a thing, they added support for that as well, but they kept the kerning editor basically the same, and added an "update [kern] feature" button.

When you click that button, the kerning data in your FL file is used to generate the kern feature. When you generate your font, the kern feature will be included.

Something like that happens when a kern table is generated in your font, too, but because the kern editor was originally built with that table in mind, it doesn't require an extra "update" step.

If the OT kern feature support feels a little tacked on in FL, it's because it was. But the kern feature is what you want in your fonts, not the old style kern table.

Joon Park

Okay, Opentype kern feature is absolutely needed, but I assume there's nothing wrong with FL's generate kern feature method? (trying to learn workflow to handle this part)

Mark Simonson

It could be better from a UI perspective, but it works.

Kent Lew

Don’t think of the FL kerning as the <kern> table, per se. When you are kerning in the FL environment, then you are just creating kern data, according to that environment’s UI and storage structure (as with any editor).

Then, when you go to generate, you specify what format you want that data compiled into.

As Mark says, the old FL structure was attuned to the old-style flat <kern> table structure. But with the addition of the ability to create kern data with kerning classes (albeit in a way that is also idiosyncratic to FL), you can just as well use this kern data to generate a fully modern {kern} feature.

And it is the latter that you want to make sure is in your generated fonts.

So, if you are doing your kerning directly in FL (as opposed to, say, exporting to UFO, kerning with Metrics Machine, and then importing an external {kern} feature), then you want to make sure that you have FL generate/update the {kern} feature when you compile, so that your latest & greatest data is put into the font.

In which case, go ahead and turn off the “Export old-style non-OpenType "kern" table” option in the Preferences > Generating OpenType & TrueType > Kerning, and turn on “Generate OpenType "kern" feature if it is undefined or outdated” option.

Joon Park

Thanks for the correction, I assumed FL kerning as old style table. I'll work with the data then generate/compile into opentype feature afterward.