How do you keep track of kerning classes (or kerning information in general)?
Ori Ben-Dor
Posts: 386
I had come up with the idea of starting with rough kerning, with very few classes, and then gradually refine it.
I grouped e.g. lowercase letters according to the height at which their body (i.e., ignoring extenders) extended the most (to the relevant side): top, middle or bottom.
For example, I put r and v in the same 1st (left) kerning class, since they both extended (to the right) more at the top than at the bottom.
For lowercase letters I ended up with only four 1st kerning classes: the v class, the a class (bottom), the o class (middle) and the x class (top + bottom).
The result of that first kerning round was quite good. Most pairs that had been inadequately-spaced before were still inadequately spaced, but almost all of them got much better.
Next I split some of those classes into two.
For every class I split, I had to kern both its child classes against every class the parent class had been kerned against.
That already started to look like a lot of mess.
(Maybe I should write a plugin that would let you split a class and have the child classes automatically inherit the kerning information from the parent class. The problem is that I use mainly FL7, which isn't plugin-friendly. Are you aware of something like that?)
The next logical step would be to continue in this fashion, possibly ending up with a separate class for almost each lowercase letter, like in many well-kerned fonts.
But how I do I keep track of the exponentially-growing number of classes and pairs involved?
Any tips? What's your method?
I grouped e.g. lowercase letters according to the height at which their body (i.e., ignoring extenders) extended the most (to the relevant side): top, middle or bottom.
For example, I put r and v in the same 1st (left) kerning class, since they both extended (to the right) more at the top than at the bottom.
For lowercase letters I ended up with only four 1st kerning classes: the v class, the a class (bottom), the o class (middle) and the x class (top + bottom).
The result of that first kerning round was quite good. Most pairs that had been inadequately-spaced before were still inadequately spaced, but almost all of them got much better.
Next I split some of those classes into two.
For every class I split, I had to kern both its child classes against every class the parent class had been kerned against.
That already started to look like a lot of mess.
(Maybe I should write a plugin that would let you split a class and have the child classes automatically inherit the kerning information from the parent class. The problem is that I use mainly FL7, which isn't plugin-friendly. Are you aware of something like that?)
The next logical step would be to continue in this fashion, possibly ending up with a separate class for almost each lowercase letter, like in many well-kerned fonts.
But how I do I keep track of the exponentially-growing number of classes and pairs involved?
Any tips? What's your method?
Tagged:
1
Comments
-
I keep the classes in alphabetical order and name them clearly. AL is the left side of A (actually the right kerns), AR is the right side of A. That way they're easy to debug. I tend to push my luck with classes... oversimplify. Sometimes it works out. The w can usually belong to vL and vR but there are cases where the angle is different enough that it needs its own class. In that case I'd copy/paste special the existing kerning make a note (check the w kerns) and keep rolling.
When I add more classes, I'll always keep it in alphabetical order. For Cyrillic, I have silly names to help me remember what they are. The soft signs Ь ь are FlipPR and flipPR (flippers). The right side of Ц ц are SlugR and slugR. (sluggers). The class names are irrelevant to the compiled font so you can name them whatever you like.
Most classes have separate left and right. My doublesided classes are usually: S, s, W, period, hyphen, left and right guillemots.3 -
Thanks. What do you mean by "I'd copy/paste special the existing kerning"? By hand for each class against which the class you've just split has been kerned, or do you have some better way to do that?0
-
I think this approach makes sense, especially for 1.x versions of the typeface. I advocate for more agile versioning of fonts. It's hard to make each font perfect and then wait for which of them will make money and which will drown in the web ocean with few licenses sold.
It would be much easier if the quality of the font is the main factor of its success, then we could focus on quality and be sure it will pay off eventually.
But I don't believe that good kerning makes the font bestseller. So I look for an acceptable kerning for the first version and then improve it later.
Like you, I also sometimes tend to make a few classes like 5-7 for caps, 5-7 for lowercase, 3-5 for punctuation. I put T and Y in the same category for example because they have a similar distribution of space. The actual spacing difference is often already regulated by different sidebearings.
The drawback of this approach is an insanely high number of pairs (fewer categories—more pairs in effect). The typeface I am working on has about 350 characters and 16000 kerning pairs. The final font file has less than 200KB so I am still not worried about it.
Anyway, far from perfect, but I like the idea of making the kerning for the first version in a day or so. I think it's fair to make the font a bit cheaper until I make the kerning be professional quality. The price should be agile too0 -
It is also worth mentioning that good kerning is more critical for typefaces intended to be used at large sizes. You can generalize more, while being nonetheless accurate, with Text faces, because of the more generous spacing (at least that is what I’d expect, despite the fact many people space Text faces tightly nowadays.)1
-
@Ori Ben-Dor
Yes, I manually copy the kerning each time I split. It's really not much work: in FLS5, I copy the glyph, paste special to the new parent and check the kerning box. Take a few seconds.
It might happen 4 or 5 times for each typeface so it doesn't add much to my workload. Sometimes my plan works out and I don't need to do any class splits.
@Igor Petrovic
I agree about versioning. But If you have a font with 350 characters and you need 16000 pairs, you need to get more agressive with your kerning classes. My current fonts have over 700 glyphs and I rarely crack 1000. It's not just about reducing workload: less kerns=less chance for errors. You'd be suprised how many seemingly reckless class inclusions turn out fine. It really depends on the font. For example, including the right side of the e in the o class. It may seemsreckless but sometimes it works out and there's a hundred or so kerns saved. With Greek you can get cheeky with the Latin classes depending on the design. And it doesn't woro out, make a split.2 -
@Ray Larabie Yes, you are completely right. I forgot that the project I was talking about is a highly specific situation. Because of its nature, I decided to draw it in Illustrator and assemble it (at least the first version) in Fontself. It has a slant but Fontself doesn't have slanted sidebearings which required more kerning than usual.
Also, I had really ugly cap-to-low gaps, and no OT features at hand which increased the volume of kerning pairs.
Anyway, I also think that e and o, for example, can go to the same class on both left and right sides and that the difference on the right side is already compensated by side bearings more often than expected. In a nutshell, I think that it's good to establish the workflow for rough but quick kerning0 -
When I was using FontLab (and it seems you are), I found that it was better to only do left or right kerning classes, no classes that applied to both left and right. This avoids most kerning class conflicts, is easier to keep straight, and is the way class kerning is implemented in fonts anyway.5
-
Mark Simonson said:When I was using FontLab (and it seems you are), I found that it was better to only do left or right kerning classes, no classes that applied to both left and right. This avoids most kerning class conflicts, is easier to keep straight, and is the way class kerning is implemented in fonts anyway.0
-
Glyphs only lets you make left or right kerning classes. You add them in the glyph info palette that appears below the current glyph just below the fields for left and right kerning values.
There is also a kerning window that shows a list of all the kerning in the font (class and non-class). You make kerning exceptions by clicking the "lock" icon in the glyph palette to unlock a kerning pair from the class value. (@ indicates a kerning class.)
1 -
I think I'm going to write a plugin for Glyphs that supports class splitting with kerning information automatically inherited from the parent class. That will make the gradual-refinement approach I've described much more manageable. Maybe it could even change the way some type designers approach kerning.
That is, as soon as I have some free time...1 -
Mark Simonson said:Glyphs only lets you make left or right kerning classes. You add them in the glyph info palette that appears below the current glyph just below the fields for left and right kerning values.
There is also a kerning window that shows a list of all the kerning in the font (class and non-class). You make kerning exceptions by clicking the "lock" icon in the glyph palette to unlock a kerning pair from the class value. (@ indicates a kerning class.)
As many things in Fontlab the approach is often "overcrowded” (or there are too many ways to approach them) but I like how effective and visual it is.
Also, the kerning windows seems to be very very similar.0 -
I use left and right kerning classes in Fontlab 7, but I generally keep a separate class for each letter and its variants, instead of mixing them. That way, I keep the number of exceptions to a minimum.1
-
@Ori Ben-Dor, the method you described sounds like you have to go through the same list over and over again, finding and fixing the incorrect kerning which you knew was going to be incorrect. There’s that old paradox that proofing kerning takes as much time as kerning itself. So, are you sure it’s more efficient than just setting up the “correct” classes in the beginning and going through the kerning list once (which takes maybe just a couple of hours with some experience)?
0 -
I use Glyphs (V2, still) but I'm actually not such a big fan of the way it handles kerning classes and exceptions. One click on a tiny lock can ruin kerning in unexpected places without a warning. Things may have changed in Glyphs 3, though...
I'm excited about this plugin by Tim Ahrens, which might turn out to speed things up a bit0 -
@Alex Visi, if you know in advance what the final classes should be and if you want perfect* kerning and are willing to put the time and effort (*perfect in the sense that every pair you've decided to kern is kerned independently of other pairs and thus can be assigned its individual optimal value), then maybe it doesn't make much sense to take my approach.
But if you don't have a clear vision of the end result or if you want the option to stop once the kerning is okay even if not perfect, then I think my approach makes sense.2
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 798 Font Technology
- 1K Technique and Theory
- 617 Type Business
- 444 Type Design Critiques
- 541 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 498 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports