# Kerning on the fly

Do anyone know any algorithm which would calculate automatically kerning of characters based on glyph shapes when user types text?

I don't mean trivial calculation of advance widths or similar, I mean analyzing the shape of glyphs to estimate the visually optimal distance between characters. For example if we lay out three characters sequentially in a line, the middle character should SEEM to be in the center of the line despite of the character's shapes. An example enlightens the kerning-on-the-fly functionality:

An example of kerning-on-the-fly:

In the above image `a` seems to be too right. It should be shifted a certain amount towards `T` so that it seems to be in the middle of `T` and `g`. The algorithm should examine the shapes of `T` and `a` (and possibly other letters also) and decide how much `a` have to be shifted to the left. This certain amount is the thing that the algorithm should calculate - WITHOUT EXAMINING THE POSSIBLE KERNING PAIRS OF THE FONT.

I'm thinking of coding a javascript (+svg+html) program that uses hand drawn fonts and many of them lacks kerning pairs. The textfields will be editable and can include text of multiple fonts. I think that kerning-on-the-fly could be one way to ensure mean text flow in this case.

EDIT: One starting point to this could be to use svg font, so it's easy to get path values. In svg font the path is defined this way:

``````<glyph glyph-name="T" unicode="T" horiz-adv-x="1251" d="M531 0v1293h
-483v173h1162v-173h-485v-1293h-194z"/>

<glyph glyph-name="a" unicode="a" horiz-adv-x="1139" d="M828 131q-100 -85
-192.5 -120t-198.5 -35q-175 0 -269 85.5t-94 218.5q0 78 35.5 142.5t93
103.5t129.5 59q53 14 160 27q218 26 321 62q1 37 1 47q0 110 -51 155q-69 61
-205 61q-127 0 -187.5 -44.5t-89.5 -157.5l-176 24q24 113 79 182.5t159
107t241 37.5 q136 0 221 -32t125 -80.5t56 -122.5q9 -46 9 -166v-240q0
-251 11.5 -317.5t45.5 -127.5h-188q-28 56 -36 131zM813 533q-98 -40 -294
-68q-111 -16 -157 -36t-71 -58.5t-25 -85.5q0 -72 54.5 -120t159.5 -48q104
0 185 45.5t119 124.5q29 61 29 180v66z"/>
``````

The algorithm (or javascript code) should examine those paths some way and determine the optimal distance between them.

-
If you're looking for a coding solution, this would be better asked on SO. Is that what you're looking for? If so, I'll migrate the question there. – Alan Gilbertson Oct 14 '12 at 7:30
I agree that this is SO question. I asked the very same question in SO, but it was closed as off topic in there. Then asked on math.stackexchange, but the same closing happened. This is third place, may be this is right place, whoever knows. – Timo Oct 14 '12 at 9:43
I don't know how the algorithm works, but InDesign can do this: "Optical kerning adjusts the spacing between adjacent characters based on their shapes. Some fonts include robust kern-pair specifications. However, when a font includes only minimal built-in kerning or none at all, or if you use two different typefaces or sizes in one or more words on a line, you may want to use the optical kerning option." help.adobe.com/en_US/indesign/cs/using/… – e100 Oct 15 '12 at 13:05
I think this is probably within scope as far as a general algorithm goes - a sequence of steps to be carried out to solve a problem. But I don't think specifics of implementation in JS or other language belong, and am editing to only mention JS as background use case. – e100 Oct 16 '12 at 12:17
I think the first order of business is to define "optimal" in a way that is useful for a machine algorithm. – horatio Oct 19 '12 at 14:15
show 8 more comments

## 3 Answers

This is a fairly simple algorithm I tried once, and may be good enough.

Render the characters in low resolution - say six or seven pixels tall (height of typical capital) about the same horizontally. You want a simple binary map of where there is empty space vs parts of the letter, on a simple low-res grid.

"Fatten" these letter maps. That is, fill each empty cell that's adjacent to a filled cell. This is to claim empty territory closest to the letter edges, so the neighboring letter doesn't get too close.

Play "horizontal Tetris" with the resulting letter maps. Let gravity act to the left. The bulging left-hand "belly" of the "a" will "fall" into the cavity under the overbar of the "T". How many cells did the "a" move? Scale that up in proportion to the actual size of the letters and that's how far to kern the actual high-res "a" leftward.

-
Thanks! To visualize your algorithm could you provide some low res image example using pairs "db", "AA", "Ta" and "c-" using Arial. – Timo Oct 19 '12 at 14:35
Good start, but I'm thinking that this may be limited where pairs of protruberant characters don't "Tetris" together, e.g. "bd", "TT", "pq", "gj" – e100 Oct 25 '12 at 15:18
@e100: At first glance those particular pairing would not have overlapping bounding boxes... – horatio Oct 25 '12 at 20:59
But generally speaking, they should be kerned tighter than "MM", "NN" etc – e100 Oct 29 '12 at 11:08

Algorithms for auto-kerning exist already. None are fool-proof and they tend to need a bit of hand-holding and manual correction of certain aspects, especially if your tracking is relatively tight.

But those algorithms are for applying the kerning to the font file, not to the letters as they are generated from the font file.

Have you considered applying auto-kerning to the font file?

Fontforge (open source) and Fontlab (commercial) contain auto-kerning algorithms. They would have a relatively steep learning curve - you have to be familiar with technical aspects of how fonts work.

There is also iKern which is a guy that offers a commercial font-kerning service whereby he kerns your font for you and does a rather excellent job. I don't know how much it would cost.

-
But the question is really "how would such an algorithm work?" - can you add any detail on how FontForge's works? – e100 Oct 29 '12 at 11:10
– thomasrutter Oct 30 '12 at 1:08

I haven't got time to think this through fully, or draw illustrations, but I had a half- idea based around first bisecting each glyph vertically.

Then for each half, determine two vertical axes: - the bisector - exactly half between left and right extremes - the "weight" axis - exactly half the ink on each side

Then move the adjacent neighbour glyph toward or away from the test half-glyph based on the relative positions of the two axes.

So, for example, in the pair "AV", the right half of the A is left-heavy and "attracts" the V; the left half of the V is right-heavy "attracts" the A, thus they are kerned together significantly.

However, I'm sure there's a flaw in that "AA" would be kerned together just as much as "AV".

-