You didn’t say which is which, but it looks to me like which ever one is on the left is very well spaced, whereas the one on the right looks very unnatural. E.g. the one on the right has too much space after the “a”, between bowls and combinations like “ty”, etc., too little after “e”, etc. I’d like to know which is which!

I’m Igino Marini, the developer of iKern. Please feel free to let me know any comment. The only thing I would like to tell you all is that iKern not only does autokerning but, mainly, autospacing too. It means that the sample Ralph published in the comparision .pdf would have been exactly the same even if the original font sidebearings were very very “arhythmic” (using a definition taken from another thread) or even random. This is a difference between iKern and InDesign’s Optical Spacing (and any other product I know).

Hello, Igino. I’m wondering if iKern is able to accept key spacing, i.e. manually set ‘correct’ spacing for e.g. n and o, which would not be altered by iKern and on which subsequent autospacing would be based? This is the one thing that seems to be missing from all autospacing/kerning algorithms I have looked at: the ability to set specific key values that will control the spacing.

Have you tried iKern with any non-Latin writing systems?

Hey, Igino,

Ever think of making an InDesign plug-in that offers your spacing and/or kerning as options right in the application?

The InDesign SDK is available for no charge: you can download it from http://partners.adobe.com/asn/indesign (I think it may be on the CD as well).

Cheers,

T

John,

Although I can’t go into a ton of detail, I know we’ve saif this in public: exactly that is the basis of InDesign’s “optical kerning” — it uses the sidebearings of just a couple of key letters in the font to determine the base spacing. I believe it’s cap H and O, maybe lowercase n and o as well.

Regards,

T

But Thomas, InDesign optical kerning will almost always change the spacing of HHH or OOO or HOH etc. It does not appear to consider any spacing sacrosanct.

Raph, what’s the point of gussying-up this typeface with auto-kerning?
Surely it was designed to work without kerning?

John,

Hmmm. Well, obviously my understanding of the optical kerning algorithms is worse than I thought. I did try to read the original patent, but my German isn’t very good (and the part that was also in French and English wasn’t very clear or helpful, IMO).

That being said, in my own experiments, I find that InD optical kerning never changes the OO and oo pairs. (Aside from any global tracking that’s been applied.)

Regards,

T

ID optical kerning varies according to text size: it won’t affect the spacing of O or o at 12pt, but it will affect it at both larger (tighter) and smaller (looser) sizes. The H and n are affected at all sizes.

As an experiment, I made a version of Minion Pro Regular with the sidebearings of the o reduced to 7 units on each side (from 37). ID optical kerning did not adjust the spacing of ooo at 12pt, but applied almost the same adjustment at 24pt as it had for the normal Minion Pro font (-2 units vs. -3 units). At 6pt, the relative adjustment was significantly differed (+18 units vs. +24 units). Changing the sidebearings of the o did affect other lowercase-to-lowercase and uppercase-to-lowercase at all sizes. This indicates that, indeed, InDesign uses the sidebearings of the lowercase o (and presumably the uppercase O) as a key to optical kerning for the Latin script.

JP: the one on the left is iKern. Sorry for not labelling it!

Nick: I probably won’t release this font with auto-kerning. I’m using it as a test for a number of reasons, not least of which is that I expect to come out of all this with a fairly well spaced font, one way or another.

Oh baby!

>T: exactly … the basis of InDesign’s “optical kerning” [is] the sidebearings of … cap H and O, maybe lowercase n and o as well.

>JH: But Thomas, InDesign optical kerning will almost always change the spacing of HHH or OOO or HOH etc. It does not appear to consider any spacing sacrosanct.

>T: I did try to read the original patent, but my German isn’t very good.

So: Adobe buys a key feature of InDesign from URW, finds out six years later it doesn’t work, and has to go to a German patent it can’t read to try, hopefully, to find out what its product actually does? We’re in worse shape than I thought.

>JH: won’t affect the spacing of O or o at 12pt,

Et voila, John seems to have discovered the one unit that InDesign/Kernus considers a designer will space correctly.

No wonder the program is hopeless. O/o is in my view the space that designers most frequently get wrong, although one could just as well say that designers most frequently get wrong the relationship between straights and rounds. It would be far better to take the interior space of n and H as an index, but that would only work for supremely rationally designed fonts.

What I think is clear from this is that no external program, yet, has the intelligence to measure stem distances. Since this is so important, one might almost think that it would be worthwhile to build the figures into the font. Yuri Yarmola has claimed that this analysis can be done in FontLab, a thousand times, but has yet to build anything based on it in all these long dark years.

Since it is a matter of such utter simplicity to build a rational spacing and kerning engine once you are able to determine the relative positions of stems and serifs, I can’t think why such a huge amount of intellectual energy has been wasted on alternative approaches.

John, one point. You find a significant difference between -2/-3 units, on the one hand, and +18/+24 units on the other, and indeed there is, typographically. But if you look at it mathematically, there is no difference at all: in each case there is an increase of exactly 50%. That is yet another example that InDesign is relying on mathematical hocus-pocus that does not correspond to typographical reality.

>I’m wondering if iKern is able to accept key spacing, i.e. manually set ‘correct’ spacing for e.g. n and o, which would not be altered by iKern and on which subsequent autospacing would be based? This is the one thing that seems to be missing from all autospacing/kerning algorithms I have looked at: the ability to set specific key values that will control the spacing.

Yes, it does. It can rely on sidebearings automatically generated or on the original sidebearings (becoming an only autokerning tool).
It can mix in any percentage new and old sidebearings, both globally and locally. It can set fixed sidebearing value by value if desired. An this is one of the features necessary as a designer.

> the one on the right has too much space after the “a”

yes I know. This is beacuse I prepared the file for Ralph “without” any manual modification to show the tool’s potential. After the “a” there’s too much space because of its autospacing. Reducing it a little resolves. And this is something every designer does when sets the very tight “a” right sidebearing.

By the way the autospacing “style” can be deciced by the user at any point between very tight and very loose. In the Ralph file test it was average toward the loose.

> the one on the right has too much space after the “a”

Note that Raph says the example on the left is iKern, so Igino is not responsible for the problem with the a.

I’m quite impressed by the spacing in the iKern example, if that is iKern on the left. Igino can you confirm what we’re looking at in Raph’s example? Was this adjusting both sidebearings and kerning?

I want to note that InDesign 2 is not using the defined size feature of OpenType fonts as starting point for the optical kerning engine too. The engine acts like every font is made for 12pt. But we all know that is true for a only few.

How does or better, does InDi recognize the original design size of the font? Effects this the optical kerning engine?

> I’m quite impressed by the spacing in the iKern example, if that is iKern on the left. Igino can you confirm what we’re looking at in Raph’s example? Was this adjusting both sidebearings and kerning?

Yes, iKern is on the left. The logical workflow is autospacing then autokerning. It’s done in the same session using the same engine, so they’re congruent as much as possible.

>a matter of such utter simplicity to build a rational spacing and kerning engine

There is nothing rational about spacing: it’s a question of aesthetic preference. When creating the algorithms which determine the “optimized” relationships in spacing software, the programmer makes decisions about what the important elements of typographic fit are, how to measure them, how they rank against one another, and what looks best. It’s taste cloaked in geekspeak.

Ideally an autokerning device would have a number of sliders, so that Bill could move his ‘o’s closer together, for instance. But I don’t think that most users would go for the hassle (the problem with MM), they’d probably prefer to have some extreme pre-sets, such as “HHP Sauce” or “Shinola”.

> There is nothing rational about spacing: it’s a question of aesthetic preference.

The matter is not to find the mathematic that lies behind vision or thinking. The practical problem, in general, is: What do I want to achieve? How can I? The first question , the harder to me, doesn’t need mathematic as Nick stated,. But the second, yes!

> Ideally an autokerning device would have a number of sliders

We’re somewhat in tune. Behind iKern there is a model very very general. My work, now, is to reduce the sliders! An example for all: one of the proprerties let you define, in a range, the distance between two capital I in a sans serif font once having set the general average width that lead to a fixed OO spacing. It’s a statistically controversial question! But it’s not the program to make the choice (even if it suggests one good based on my experience) but me when I set the imput. Then the program apply my choice where needed.

> Changing the sidebearings of the o did affect other lowercase-to-lowercase and uppercase-to-lowercase at all sizes. This indicates that, indeed, InDesign uses the sidebearings of the lowercase o (and presumably the uppercase O) as a key to optical kerning for the Latin script.

Not only. If, for example, one cuts both sidebearings of a “m” the couple “mm” will be tigher even after autokerning.

Igino, what principles does it work on?

To illustrate that there is no ideal “optimization” of fitting, here are four different strategies, equally valid, for spacing the same word (font: Georgia).

Wonderful illustration. Thanks, Nick.

The ikern is very impressive. What I don’t understand is the methodolgy for using it — you have to send a file to Inigo Marini, and not buy a program? I don’t get that.

So the iKern is in the left … damn! If iKern can be made to work this well with any font, then there isn’t much point in spending weeks going through the combinations to make a font look well spaced from an end result point of view. At least for myself, I doubt I could get those results without spending a lot of time adjusting values. Given that it was my first try, so I’m still learning, I’m still adjusting kerning for my Marquet (you don’t want to know how long its taken …!)

However, I imagine that the software will end up adding kern pairs between pretty much every letter pair (kind of like those Adobe Pro fonts). Without kerning classes in larger Unicode charsets, this could result in a really huge file! Is there any way you can get this software to automatically generate efficient OT kerning classes? (ah, wishful thinking…)

BTW, kudos on this software, the results are really oustdanding

> Is there any way you can get this software to automatically generate efficient OT kerning classes? (ah, wishful thinking…)

Internally iKern works with classes!

> The ikern is very impressive. What I don’t understand is the methodolgy for using it — you have to send a file to Inigo Marini, and not buy a program? I don’t get that.

I still haven’t finished:
- user interface
- CFF parsing (now only TTF)

Until then I consider iKern as beta so test fonts are welcome.

> To illustrate that there is no ideal “optimization” of fitting, here are four different strategies, equally valid, for spacing the same word (font: Georgia).

iKern can do overlap (see examples):

Does anyone know of a current e-mail address for Igino Marini (inventor of iKern)? The two on his web page appear to be defunct.

The last one I have from him is iginomarini at yahoo.it. I've been meaning to chat with him about kerning stuff. Hope your discussion with him is fruitful!

Coincidentally, I just received an email from him at his yahoo address about a week ago:

"David, I closed the email accounts because of the spam growing. Yes. I'm still alive. I've continued developing iKern and now I'm working on a version of the Fell Types (OpenType; Western, CE, Baltic & Turkish). When finished I will prepare some web pages to explain my theory of letterspacing for my new site: www.ikern.com. New ideas to follow."

Iam sorry maybe its an offtop. But why there is only a Windows - based version ? Could somebody reccommend something like this programm but for Mac ?

Hi Igino
I have bumped into the iKern page from time to time in the past. It looks interesting, but the big question remains: kerning classes. Is there currently any integration from your tool with Fontlab's metrics- and kerning classes? I would suppose that it would be a requirement for your tool to catch on?

Another thing is that I am working on something, so would you have the capacity to run it through iKern, or has this Typophile attention crowded you with samples?