Um... Zero equals no kerning. But I must be misunderstanding your post.

What I can tell you is this: the order in which your kerning is listed is super duper important, and I hope that someone with The Answer on this issue - Adam? John? Mark? Tom? - can post a fantastic and concise statement.

Because there are several ways to skin a kerning class cat, but only several. There are also a jillion ways which will fu*k everything up.

That's exactly the issue at hand. I had some of the wrong glyphs assigned to a certain class. They were kerned accordingly, and I wanted to essentially delete the kern pairs for those erroneously classed glyphs. I wanted to set them all back to zero with the convenience of their own class.

btw... Happy Thanksgiving Eve.

Silas,

If you want to make a zero-valued exception to a nonzero-valued class kerning pair, then I'd make the exception -1 (or something that you don't use in your kerning table), then generate the "kern" feature using Kerning Assistance, copy-paste the contents of the "kern" feature from the OpenType panel to a text editor and search/replace -1 with 0.

Not the most elegant solution but should work if you *really* want to do it that way :)

Best,
Adam

Thanks Adam.

Is this something that could be fixed in a future version? Should I submit a Problem Report at fontlab.com?

Aha! Now I see what you're saying: You've got some kerning which you DON'T want, and you're trying to reset those pairs to zero. You can't do that. And it's definitely not a FontLab bug.

Kerning is cumulative, so if you have one line of your kern feature which kerns a pair -50, and you have another line which kerns the same pair -25, the result will be a kern of -75.

If you have one line of your kern feature which kerns a pair -50, and you have another line which kerns the same pair 0, the result will be a kern of -50.

If you have one line of your kern feature which kerns a pair -50, and you have another line which kerns the same pair 50, the result will be a kern of 0.

What you need to do is: figure out where your problem lies and fix it at root. Having two competing kerns is bad coding.

chester: FontLab spits an alert to the Output Panel if you try to compile kern feature data containing duplicate/similar lines (identical or differing values).

Adam: I admit that I didn't actually follow your advice, and now I realize what you were suggesting. It's not that I wanted to make an "exception" to the class. If I wanted to do that, I'd simply scratch the glyph(s) from the class. That's what I did, before I manually reset the offending kern pairs to zilch.

The issue is whether FontLab should simply apply a zero value to the rest of the pairs in a kern class -- nevermind the raw kern feature data. Any change in value is applied for any other integer. Seems like a simple enough action to allow a zero-value to be applied as well. Heck, Fontographer does it.

Silas, indeed FontLab tells you about all kinds of things. If you compile a kern of uppercase "L"s (including those with accents) and uppercase "T's, (including those with accents), you get a message that some kern pairs may never be accessed. FontLab is just being dilligent. (Or a nanny.)

Which FontLab are you working with? In my experience FL Studio 5 is much better about reporting stuff than FL45 is. And it doesn't necessarily stand up and point out double kerning if you have some glyphs in more than one class.

But... There is no need for "zero value" kerning. It's like having an instruction to "do nothing". It's a waste of time and energy to read something which doesn't have any instructions attached.

There actually is a need for zero-value class kerning... to save time in making changes to the kern feature data. The whole purpose of class based kerning is to save HUMAN time and energy. It's not such a drain for a computer to read zero-data if that's what the user has intended.

In my situation, it was not an instruction to "do nothing." It was an instruction to change the existing kern feature data from the existing, erroneous values to zero for the glyphs in whatever class I chose to handle them by.

As I said, Fontographer can do it. You set the kern value of one pair in a kerning assistance group and the linked pairs follow suit... even for a zero value. It's good for curing those "jillion ways" you mentioned.

Adam... you still there?

Class-based kerning and "Kerning Assistance" in FontLab does not work the same as Kerning Assistance in Fontographer. It would be nice for those of us who learned to use it in FOG, but it simply doesn't.

Class-based kerning in FL has a dual purpose:

One is for the Kerning Assistance feature, which is sort of like KA in FOG, but more limited. It is for when you are building a kerning table (NOT the "kern" OT feature) for a Type 1 or TrueType font.

The other is for building the "kern" feature in OpenType fonts.

In either case, it is only the primary glyph (the one with the apostrophe after it) in the class that matters. This is the only glyph you should be kerning. Other glyphs in a class should be left unkerned. (If you do kern them, you will get those "may never be accessed" messages.)

If you are building a conventional kern table, you set up your classes, kern the primary glyphs, and then hit the Expand Kerning button in the Kerning Assistance dialog. This builds the kerning table including all the other pairs implied by your classes.

If you are building the kern feature for an OT font, you set up your classes, kern the primary glyphs, and then hit the Apply and Save button in the Kerning Assistance dialog. This builds the kern feature. It does not build any new kerning pairs.

All of this assumes you're using FL 4.6. As I understand it, this stuff is a bit less confusing in FontLab Studio 5, but I'm still waiting for the Mac version.

The Kerning Assistance facility in FOG was much more flexible and powerful, but would not be much use for building a kern feature. It had no concept of a "primary glyph" which is the basis for class-based kerning.

This is not about the zeros ...

Mark Simonson wrote:
"The Kerning Assistance facility in FOG was much more flexible and powerful, but would not be much use for building a kern feature."

Both follow a different logic. Fontographer's kerning assistance is as it is because it does *not* have to result in class based kerning.

"... It had no concept of a “primary glyph” which is the basis for class-based kerning."

The primary glyph is FontLab's approach to class based kerning. But the OT kern feature only needs the definition of classes, the kerning of classes against others, and the kerning of individual glyphs against others which are the exceptions. One could consider other approaches to class-based kerning in FontLab which would not require primary glyphs.

"In either case, it is only the primary glyph (the one with the apostrophe after it) in the class that matters. This is the only glyph you should be kerning. Other glyphs in a class should be left unkerned. (If you do kern them, you will get those “may never be accessed” messages.)"

Well, kerning other (not primary) glyphs will create the exceptions which are not class based.

The "may never be accessed" messages indicate that one glyph is part of more than one kerning class which is strictly forbidden. Unfortunately, this happen all the time.
To avoid this, just create separate sets of kerning classes for first-glyphs-in-kerning-pairs and for second-glyphs-in-kerning-pairs. (In the Kerning Assistance then, for first-glyphs-in-kerning-pairs classes, only mark classes serving as exactly that; and for second-glyphs-in-kerning-pairs classes, only mark these.) But still, you need to take care that e.g. an "a" may exist only once among the first-glyphs classes, and only once among the second-glyphs classes.
Normally, this works fine.

FontLab's kerning assistance may differ from Fontographer's. But it makes perfect sense considering the desired output, the kern feature. (Only the idea of using a primary glyph I consider as unhappy as this imposes unnecessary constraints.)

Mark: I understand the way the class tables interact with the kern feature data. I'm suggesting that they also communicate zero values. Regardless of the primary glyph organization, it would be nice to be able to 'undo' or 'reset' or 'delete' the kern value for an entire class. Setting the kern value for the primary glyph seems like the most logical way.

pardon... Setting the kern value for the primary glyph to zero seems like the most logical way.

I'm not sure if I follow.

Class kerning in FontLab is made by linking one or two classes to an individual pair. The individual pair is always defined between two glyphs. One or both glyphs can be key glyphs in a class.

Let's say we have the kerning pairs:
/a/c -20
/a/e -30
/c/e 10

And we have three classes:
_a: a' aacute agrave adieresis
_c: c' ccedilla
_e: e' eacute egrave

Each class has one key glyph marked with the single quote and one or more dependent glyphs.

Both in FontLab 4.6 and FontLab Studio 5, you only kern the key glyphs so you always have individual kerning pairs for just the key glyphs when working in class kerning. The problem in FontLab 4.6 is that you cannot SEE the kerning for the dependent glyphs in the Metrics Window.

So if you preview the "/a/c" pair in FontLab 4.6's Metrics Window, you'll see the kerning applied but if you look at the "/a/ccedilla" pair, it will look as if it were unkerned.

To see the kerning applied, you need to build the "kern" feature (Tools / Kerning Assistance / Apply and Save), then "Compile" the OpenType features in the OpenType panel and finally preview the kerning in the OpenType Features panel.

Alternatively, you can expand the kerning, i.e. physically copy over the kerning values from the key glyphs to the dependent glyphs. Then you'll see the kerning in the Metrics Window but it's no longer class kerning. Each pair is now an individual pair that happens to have the same value. If you change the kerning value for "/a/c", the kerning value for "/a/ccedilla" will remain the same. You can still "expand" the kerning again which will again copy over the "master" kerning value from the "/a/c" pair to the dependent glyphs, thus overwriting the previously expanded indivdual pairs.

In FontLab Studio 5, it has been changed. You see the class kerning pairs live in the Metrics Window. By default, dependent glyphs are displayed in dark blue and key glyphs in black. If you watch "/a/c /a/ccedilla" in the Metrics Window and change the kerning value of "/a/c", the *virtual* kerning value of "/a/ccedilla" will update instantly. But you need to remember that there still is just ONE physical kerning pair here: "/a/c".

Of course, you can define a kerning exception for /a/ccedilla", thus replacing the virtual kerning pair by a real kerning pair. This is what expanding the kerning does for all the pairs, or you can do it for a specific pair. If you switch FontLab Studio 5 to "Class kerning with exceptions" and drag around the "/a/ccedilla" pair, a new physical kerning pair will be defined. It can have the same or a different value from the "/a/c" pair, but once it's there, the link between the physical "/a/c" pair and the virtual "/a/ccedilla" pair is no longer there because there are two separate physical pairs now: "/a/c" and "/a/ccedilla".

Now, what happens if you set a kerning value to 0 in FontLab 4.6 or FontLab Studio 5? Such kerning pair is automatically deleted. This means that if I had two pairs: "/a/c -30" and "/a/ccedilla -30" and set "/a/c" to 0, I end up with just only one pair: "/a/ccedilla -30". If I do Kerning Assistance now (no matter whether it's in 4.6 or 5.0), the "/a/ccedilla -30" will never automatically vanish because "its master has been killed". The "/a/ccedilla" pair is a ronin now, a masterless warrior. The "/a/c" pair does no longer exist so there is nobody to tell the "/a/ccedilla" pair to go bananas as well.

The handling of kerning in FontLab Studio 5 has been much improved but you still need to think about the actual kerning pairs that "carry the burden". Each class kerning value is still attached to one particular key glyph combination.

In FLS5, there are three kerning modes: "Class kerning", "Class kerning with exceptions" and "Class kerning in key pairs only".

When "Class kerning in key pairs only" is switched on, you can only change the kerning values for the key glyph and the dependant glyphs are locked from being changed. So if you have the situation as detailed above (3 kerning pairs, 3 classes), you could define or change a kerning pair for "/a/c" but not for "/a/ccedilla". This mode is pretty safe to work with because you always know which glyphs you can kern.

When "Class kerning with exceptions" is activated, then kerning key pairs defines key kerning pairs (which are reflected in the virtual kerning pairs for the dependent glyphs) but if you kern a dependent pair, an exception is created, i.e. a new physical pair. When I kern "/a/c", I get one physical pair "/a/c" and automatically a number of identical virtual pairs for "/aacute/c", "/agrave/c", "/a/ccedilla" etc. But if I explicitly kern "/a/ccedilla", then a new physical pair is created and that pair disassociates itself from the key pair. The other virtual pairs remain linked.

The third class kerning mode "Class kerning", which is on by default, works like this: if you have classes define as in our example, the key kerning pair is defined or modified no matter whether you kern key glyphs or dependant glyphs. This is important to realize and remember: in this mode, when I kern "/a/c" or when I kern "/a/ccedilla" or when I kern "/aacute/c", *always* the physical "/a/c" pair actually gets kerned (and the virtual pairs follow). So the concept of key glyphs is still there but you can SORT OF forget about it. You can use a "live language" text file and kern around your glyph combinations, and FontLab Studio 5 will make sure that always the key pairs get the values.

So if you have kerning classes defined like this (theoretically):
_flatflat: n' m h u ntilde uacute ugrave
_flatround: p' b
_roundround: o' oacute ograve
_roundflat: c' d e q ccedilla eacute

And you type in "/b/e" in the metrics window and assign the kerning value -20 to that pair, what you're actually doing is you're assigning the kerning value -20 to the physical "/p/c" pair. There is no physical "/b/e" pair at that moment -- it's only virtual.

Again, you can make it physical by defining an exception (for that switch to the "Class kerning with exceptions" mode) or by expanding the kerning (in Kerning Assistance). If you have expanded your kerning, you'll have many pairs:
/p/c -20
/p/e -20
/b/c -20
/b/e -20
/b/q -20
etc.

Let's assume that for /b/q you now define a different value, -30.

Now, FontLab Studio 5 has the mechanism of compressing kerning, which will do the opposite: it will remove those physical kerning pairs that can be replaced by virtual pairs. After compressing, only
/p/c -20
/b/q -30
remain.

/p/e, /b/c, /b/e will all be removed as physical pairs and replaced by virtual pairs. The class definition again links them to the /p/c pair. Compressing will not remove /b/q because it has a different value so it remains as an exception.

But what happens if I have the situation:
/p/c -20
/p/e -20
/b/c -20
/b/e -20
/b/q -20
and then set /p/c to 0?

The physical pair /p/c will be removed. If I now compress the kerning, all these pairs will remain as physical pairs:
/p/e -20
/b/c -20
/b/e -20
/b/q -20

Why? Because -- as I explained earlier -- they're ronins now. Their master (the /p/c pair) has been deleted from the kerning table (by setting it to 0) and therefore they don't have a way to return to being a virtual pair.

In other words, if you expand, virtual pairs turn into physical pairs. If you compress, physical pairs turn into virtual pairs but only then if they have a potential key physical pair that they can be linked to. Setting a physical pair to 0 removes that pair from the pairs list so the ability to "compress" the others is lost. Of course, you can rewrite your class definition by moving the "'" marker to some other glyph. If you set /p/c to 0, you could change:
_flatround: p' b
to
_flatround: p b'

From now on, the /b/c pair is the master, not the /p/c. The ronins have a master again and could be compressed again.

But note that if you change your key glyph within your class, then the virtual pairs will not retain the old kerning values. Consider:
Class
_H: H' N M I
Physical pair
/H/O 20
Virtual pairs
/N/O 20
/M/O 20
/I/O 20

When I go ahead and change the class definition to:
_H: H N' M I
I'll have:
Physical pair
/H/O 20

This means that the virtual pairs did not "magically" migrate to the new master.

However, if I'd like that to happen, I could expand kerning, reassign the key glyph and then compress kerning.

So, after expanding the kerning, I'd have:

Class
_H: H' N M I
Physical pairs
/H/O 20
/N/O 20
/M/O 20
/I/O 20

Then I change the class definition so I have a new key glyph
Class
_H: H N' M I
Physical pairs
/H/O 20
/N/O 20
/M/O 20
/I/O 20

and finally I compress kerning to get:
Class
_H: H N' M I
Physical pair
/N/O 20
Virtual pairs
/H/O 20
/M/O 20
/I/O 20

I hope this very long posting has made the whole situation a bit more clear :)

Regards,
Adam Twardoch
Fontlab Ltd.

Both follow a different logic. Fontographer’s kerning assistance is as it is because it does *not* have to result in class based kerning.

...

Well, kerning other (not primary) glyphs will create the exceptions which are not class based.

Yes, I realize that. I guess I mean for practical purposes. In my experience, exceptions in the kern feature which are not class based cause problems in some applications, specifically, the kerning is not recognized. (I seem to recall that this is because of some limitation in the Adobe FDK, upon which FL's OT feature compiling language is base.)

The upshot is that you have to make sure there are no non-class based kerning pairs in the kern feature. The only way I know of to do this is to only kern the primary glyphs.

Mark,

no no, you can mix classes and individual glyphs. A typical kern feature of an OpenType font looks like:
feature kern { # Kerning
# Latin
lookup kern1 {
pos T w -22;
pos T @_a -30;
pos @_Y w -25;
pos @_Y @_a -31;
} kern1;
} kern;

So there are single-to-single, single-to-class, class-to-single and class-to-class pairs. Exceptions are always placed before the rules.

FontLab 4.6 builds the kern feature in a way that is not always compatible with ATM 4.1/4.6. FontLab Studio 5 is better there.

Regards,
Adam

Adam,

Then why does InDesign not see any kerning in a font when I include anything but classes in the kern feature?

Maybe I'm doing something wrong, but that's the only way I've been able to get kerning to work with my OpenType fonts.

Adam,
from your post I take it that the order of kerns using classes and glyphs is:
glyph glyph
glyph class
class glyph
class class

I have noticed that kern features with things in the wrong order don't work.

I now build my kern feature by first making classes for each letter with its accents:

@_kernA1 = [A Aacute Agrave Acircumflex Adieresis Atilde Aring Acaron Amacron Abreve Ainvertedbreve Adoublegrave Adotabove Aringacute Adieresismacron Aogonek Anocross];
@_kernAE1 = [AE AEacute AEmacron];
@_kernB1 = [B];
@_kernC1 = [C Cacute Ccircumflex Ccaron Cdotaccent Ccedilla];
etc.

Then in the kern feature:
pos @_kernA1 @_kernC1 -20;
pos @_kernA1 @_kernG1 -20;
pos @_kernA1 @_kernT1 -95;
pos @_kernA1 @_kernV1 -90;
etc.

This results in the majuscule A and all of the majuscule A with accents kerning -95 with majuscule T and all of the majuscule T with accents. And on and on and on. Until the crack o' crack o' dawn.

I get to recycle big chunks of my OT coding, and I don't go anywhere near the Collections & Classes panel.

I'm curious to know how everybody else does it?

c

Thanks again for the wisdom, Adam, but I think I can clarify my proposition a tad bit more...

My issue is with expanding the kerning. Zero values are ignored in this process, but I'd like for any zero-values set on the primary glyph in a class to be applied to the rest of the class. To use your poetics: I wanted to apply a zero-value to the rest of those would-be "ronins."

I'd just like to have some way of selectively deleting kern pairs (in the all too common scenario that they are botched with a class-based guffaw.)

Roger that?

Chester,

This has to do with the basics of OpenType processing. Once a given glyph combination is hit, the OpenType machinery stops looking for it and moves on to the next pair. So if you have the "T agrave" glyph-glyph combo intended as an exception to the "T a" class-class combo, it had better come first.

In some senses, it's exactly the same reason you put "ffi" ahead of "ff" in the 'liga' feature.

Regards,

T

> My issue is with expanding the kerning.
> Zero values are ignored in this process

I thought I explained this already: there is no such thing as zero-values kerning pairs. If you set the value of a kerning pair to zero, the kerning pair is removed. It really becomes "nada".

But I still don't understand your issue. Is your scenario the following:

1. You define 2 classes:

_A: A' Aacute Adieresis
_Y: Y' Yacute Ydieresis

2. You define 2 pairs:

/A/Y -30
/A/V -30

3. You expand your kerning. You get:

/A/Y -30
/Aacute/Y -30
/Adieresis/Y -30
/A/Yacute -30
/Aacute/Yacute -30
/Adieresis/Yacute -30
/A/Ydieresis -30
/Aacute/Ydieresis -30
/Adieresis/Ydieresis -30
/A/V -30
/Aacute/V -30
/Adieresis/V -30

4. You delete the pair /A/Y (you set its value to 0).

Now you have 11 pairs:

/Aacute/Y -30
/Adieresis/Y -30
/A/Yacute -30
/Aacute/Yacute -30
/Adieresis/Yacute -30
/A/Ydieresis -30
/Aacute/Ydieresis -30
/Adieresis/Ydieresis -30
/A/V -30
/Aacute/V -30
/Adieresis/V -30

Is this the scenario you're following?

Since the pair /A/Y is gone, FontLab has no information about it anymore. Therefore, it has no knowledge as for how to eliminate the other pairs. You cannot copy "nada" to something else. Because nada isn't.

A quote from Tom Stoppard should illustrate the problem:

Rosencrantz: Do you think Death could possibly be a boat?
Guildenstern: No, no, no... Death is not. Death isn't. Take my meaning? Death is the ultimate negative. Not-being. You can't not be on a boat.
Rosencrantz: I've frequently not been on boats.
Guildenstern: No, no... What you've been is not on boats.

I realize that since FontLab 4.6 lacks the immediate visualization of dependent (virtual) kerning pairs, you need to expand kerning in order to see it in the metrics window. In FontLab Studio 5, you won't need to expand kerning at all except at the very end of the font development when creating a PostScript Type 1 font. During the design stage and when working on OpenType fonts, you won't touch Kerning Assistance at all. You'll define your classes in the Classes panel (you can use the automatic class building feature there) and then you just go ahead and kern in the metrics window -- both real and virtual kerning pairs will be always visualized. Of course, in FontLab Studio 5, if you set the value of a real pair to 0, i.e. delete it, the dependent virtual pairs will immediately follow -- you won't need to do anything.

So I guess, the ultimate answer for your question is: get FontLab Studio 5 for Windows now or wait until the Mac version is released.

Regards,
Adam

Is this the scenario you’re following?

Yes.

Since the pair /A/Y is gone, FontLab has no information about it anymore. Therefore, it has no knowledge as for how to eliminate the other pairs.

The class is still active. Now, what I'm suggesting is that the class continue to serve its purpose, and by some magical feat of software engineering (ie: the Expand Kerning feature) register the fact that the primary pair HAS BEEN DELETED and go about DELETING THE REST OF THE DEPENDENT PAIRS.

This is, perhaps rightfully so, a philosophical matter, but existentialist cinema does not illustrate the fact that the software is not behaving logically. Software is not poetry. It is machinery and should perform according to the user's expectations. My expectation is for the class to continue to determine the values of the dependent pairs... not to produce "ronins" or Rosencrantzes. (Although I do love a dash of absurdism in my theatre.)

I realize that since FontLab 4.6 lacks the immediate visualization of dependent (virtual) kerning pairs, you need to expand kerning in order to see it in the metrics window.

ok... this is where I observe FontLab's behavior to be deficient...

From what you are saying, Adam, FontLab, by inherent design and intention, is wholly unable to propagate the DELETION of primary glyph kerns to the dependent glyphs of a class via the Expand Kerning process because it isn't designed to understand "nada." Remarkable. Our deranged little ronins go running amok.

I'd like to see the Expand Kerning feature kill the ronins. Actually, let's call them vampires... like the Lost Boys version. You kill the head vampire and the rest of 'em get dusted (or cease to be half-way vampires). You're Feldman. I'm Haim.

OTF Kern Feature classes WILL reflect the deletion because those would-be ronin vampires were all imaginary anyhow. But this has nothing to do with FL4.6. I need to keep dreaming about Studio 5 for Mac.

As for my own comically absurdist analogy, which I find slightly more apropos given your sales pitch for a an upgrade that may very well continue "pining for the fjords"...

http://www.mtholyoke.edu/~ebarnes/python/dead-parrot.htm

Silas,
it seems to me that if you just do your kerning as a kern feature, you can have your cake and eat it.

You can make you classes and kern feature in the way I described above, including making "zero kern" relationships if you so desire. You use the Preview panel to view the results of your work, and you don't have to go near the Collections/Classes panel or Kerning Assistance. Use the Metrics panel to tweak sidebearings only. (In FontLab Studio 5, the compiled kern feature results are reflected in the Metrics panel.)

So, in code...

Build a kern feature by first making classes for each letter with its accents:

@_kernA1 = [A Aacute Agrave Acircumflex Adieresis Atilde Aring Acaron Amacron Abreve Ainvertedbreve Adoublegrave Adotabove Aringacute Adieresismacron Aogonek Anocross];
@_kernAE1 = [AE AEacute AEmacron];
@_kernB1 = [B];
@_kernC1 = [C Cacute Ccircumflex Ccaron Cdotaccent Ccedilla];
...
@_kernX1 = [X];
@_kernY1 = [Y Yacute Ygrave Ycircumflex Ydieresis Ytilde Ymacron];
@_kernZ1 = [Z Zacute Zcaron Zdotaccent Ezh Ezhcaron];

Thomas,
thanks for the info about logic of ordering in OT features. If it's confusing to an old-ish hack like me, it's probably pretty opaque to a newbie. But I kept my basic HTML and BASIC and LOGO knowledge, which has been greatly beneficial to me.
c

You use the Preview panel to view the results of your work,

chester: My Preview panel doesn't show the kerning... not even the hardcoded primary kerns.

...the Opentype Preview panel, that is.

You have to build and compile the kern feature, then switch to the OpenType Features tab of the Preview panel and click the checkbox next to the kern feature. Kerning pairs built with the Metrics window will not appear, only pairs defined in the kern feature.

Silas, Mark answered your question...

I completely advocate working your kerning as an OT feature, and then generating a kern table at the end of the process, once you're happy with the results. FontLab Studio 5 has a nice new feature where you can generate a 1:1 kern feature from your kern table. It's then only a couple of hours in BBEdit to (manually) convert that to a kern feature like what I posted earlier in this thread.

I may post my code on my site for people to download and play with. It will be the kern feature from an existing font, but should be a good start for folks.

Stand by...

I think I've discovered another bug.

The Kern Feature wouldn't compile when it was the only feature defined. Rather, it wouldn't show up in the features list in my OpenType Preview panel. I added a liga feature with a custom sub and THEN they both appeared.

All is (almost) well. Can anyone else replicate this cute little anomaly? Is this not an anomaly?

Silas,

"I think I’ve discovered another bug. The Kern Feature wouldn’t compile when it was the only feature defined. "

Yes, it's a bug that has been fixed in FontLab Studio 5.

"software is not behaving logically"

Actually, I think the software is behaving logically. It's just not behaving the way you expect.

As I explained, in FontLab Studio 5, this problem will no longer be an issue, at least not in the majority of cases, since you won't be expanding the kerning on a regular basis but rather working with real and virtual pairs until very late in the process. Virtual pairs *do* get deleted when the corresponding real pair gets deleted. It's the virtual-become-real pairs (after expansion) that stick. But since you (practically) don't need to expand in FontLab Studio 5, you won't need to worry about virtual-become-real pairs.

Also, in FontLab 4.6, you can kill all the vampires/ronins with some 20 lines of Python code. The feature itself is not built into the software but thanks to Python, you can implement the feature yourself.

Regards,
Adam

Right, I have posted a text file covering class-based OTKerning for download here:
http://vllg.com/files/OTKerning/

Silas, Adam, I just tested a font with only the kern feature, and it compiles perfectly. It does have the "magic bullet" lines of feature:
@_notdef = [.notdef];
in the class list and:
pos @_notdef @_notdef 0;
as the first line of the kern feature.

Try throwing those into your file and see what happens.

chester: that .notdef trick isn't doing its trick. I'm losing my marbles.

It's 60 degrees in Chicago at the end of November. Dipping back down into the 30's tomorrow. I think I'll go for a walk and soak up the last of the fresh air -- maybe come back to this stuff with a clear head.

Chester, thanks for posting that. I'm going to try your method next time. It looks more straightforward than the standard way (i.e., using the Metrics window and the Apply and Save button).

One thing I might add: When I set up my classes, I divide them into left and right sets. For example, @_kernlA is for when the A is on the left side of a kern; @_kernrA is for when the A is on the right side. The content of these classes depends on the design of the font, and I always analyze and organize by shape (for each side) before even starting to kern.

It looks like your class definitions are more generic, but that would make them easier to use with different fonts.

Mark, indeed, I have worked with classes similar to what Adam has described where shapes are addressed, so that you can kern, say, "V" and "all lowercase glyphs with round left sides." (I did this on "Mavis", but ran into some problems, and found it hard to keep organised with 1000+ glyphs, including alternates, so have resorted to the tried and true method I posted.)

Also, what I posted only deals with the kerning of letters. There are also classes which keep track of glyphs for subsitution features like smcp and tnum and whatnot.

Thanks Chester!

I find myself using the Generate Classes function quite often (in Classes panel). It analyzes the shapes of the characters between the appropriate lines (baseline, x-height, caps height) and combines similar glyphs into classes. Sometimes, it's good to temporarily change your caps height or x-height in Font Info (put them 10 units lower) so subtle differences at the top of the glyphs don't confuse the algorithm.

Adam

I am just marking this thread because I am trying to figure a way to clear kerning exceptions to class based kerning both globally and individually. I don't want to set a new exception to zero, I want to delete the exception and have the pair respond to the class kerning and not have a red number in it.

ChrisL