Have a look at Minion Pro’s feature file
http://www.adobeforums.com/cgi-bin/webx?50@@.3bb58628

The code that is inserted into the OpenType panel when you hit the “+” button is a stub—it’s incomplete and you are expected to complete it. You got halfway there by changing “xxxx” to “onum,” but you’ve got to finish the job. “sub by ;” needs to say something like “sub one by one.onum ;”. This is what is called a one-to-one substitution in OpenType feature speak. What it means is that the normal “one” will be substituted by “one.onum” when the user asks for old style numerals. You have to add a line like this for every number. It should look something like this:

feature onum {
sub one by one.onum ;
sub two by two.onum ;
sub three by three.onum ;

and so on, finishing up with:

} onum;

It can get more complicated than this—for instance if you have both proportional and tabular figures—but that’s basically it. (It’s all covered in the manual, by the way.)

Or make a class for num and a class for onum and sub the class.

ChrisL

Here is the code:

feature onum { # Old style numerals
sub @num by @onum;
} onum;

Thanks a lot everyone. Figured it out. I would have had it earlier if I had only scrutinized the manual :).

And subing classes seems like THE way to go.

I posted Kaled Sans for the cirtique over in the neighborhood. You can see my old style’s feature at work in this image.

Now, one more question: Are there advantages to doing the kerning as an OT feature as opposed to the kerning table in metrics? Since I’m jsut starting to kern, should I just go for the OT kern feature?

Emir

That depends. The spec for PostScript-flavored OT (CFF) fonts says that a kerning table is not supported, meaning you must use class kerning. TrueType-flavored OT (TTF) fonts may have either or both. In fact, FontLab will let you include either or both in both flavors of OT fonts.

That said, class kerning is the way to go. It takes a bit more planning, but it’s more efficient and thorough.

It seems there was another aspect to your question:
For direct visual control, you should use the Metrics Window for kerning. This also allows you to use classes. Then — whether you used classes or not — you go to the Metrics Assistance panel and hit the “update kern feature” button which generates a kern feature for you.
This way, your plain kerning table and the kern feature are (or at least: could be) equivalent for one is generated from the other.

I think you need both because some apps don’t read the opentype kern feature and need the table. That is why I think Karsten’s solution is best. It gives you both and they are the same. Also, you can see it well in the metrics window as you do it.

ChrisL

Here’s the deal, though: With CFF fonts, the old-style kern table will never get used. OT-savvy apps will use the kern feature; non-OT-savvy apps get a synthesized kern table based on the kern feature. So, even though you can include a kern table in an OT CFF font using FontLab, it will simply be taking up space.

Incidentally, there was recently a discussion about this on the OpenType list. Adam Twardoch was advocating that kern tables should be supported in OT CFF fonts just as they are in OT TTF fonts. Judging from the discussion, it doesn’t sound like it will likely happen.

Here’s the deal, though: With CFF fonts, the old-style kern table will never get used. OT-savvy apps will use the kern feature; non-OT-savvy apps get a synthesized kern table based on the kern feature.

Oh yes, I only addressed one question, how to get consistent results among kern table & kern feature.

You are right, according to the current specs, only the kern feature should be present in PS-flavored OTFs. Personally, I stick to this. Too much redundant information in OTFs already ... (Also, in an earlier test I had the impression that some application ignored kerning completely if both table and feature were present, but forgot the details and cannot — nor do I want to — reproduce this.)