When I was working on the classes in Black Monday I did a copy/paste from the font window to Textedit, saved it to a text file, used this command:

tr '/' '\n' < ./bmonday_encode.txt > ./bmonday2.txt

to insert real line breaks, and this one:

sed -e s/$/.alt1/g bmonday_formatted.txt

to create my big alternate classes. This allowed me to deal with the classes in Textedit where I can use 14-point Verdana to spot any mistakes before I work them into Fontlab.

And remember, save your OpenType classes any time you edit them in Fontlab. You will accidentally use the evil class sorting button that deletes them at some point, so be ready.

Yeah, that "some point" happened today! #$%^&*(

I'll take a look at those text-editing tips.

If you're talking about classes for layout features and not kerning (well, kerning is a layout feature, but you know what I mean), then a lot of it comes down to what makes the most sense for you as a font editor.

There is sense in setting up a big lowercase class, @LC = [a b c d ...], and having a matching small caps class, @SC = [a.sc b.sc c.sc d.sc ...]. Such classes could include all the accented characters. These classes could be fairly easy to manage with a visual editor like FontLab.

When it comes to some contextual substitutions, you might want a class of "all letters" for some particular contextual rule, so you could then make a "class of classes": @LETTERS = [@LC @UC @SC].

If you're using a text editor and a features file, you might eventually find, as I did, that editing large classes like this can be difficult. Complementary classes have to match 1-to-1, and if there's an error, you'll find yourself poring over long class definitions trying to find the error.

In practice, you can specify basic letter ranges in shorthand, e.g. [a-z], so this can help. But I've found in some cases that it's helpful to see a list of single substitutions, e.g.

sub dollar by dollar.oldstyle;
sub cent by cent.oldstyle;

and so on. It's tempting to start by putting everything in classes, but it's not always the best solution.

I suspect a lot depends on what font editing program you have.

I too use a text editor, but one that has numerous capabilities, such as a column mode, sorting, change to case, etc. I use Vedit, but it is out of date. EditPad Pro would be much better.

I can describe a couple things that I do, but this should be taken only a suggestion of how to think about things, not a recipe.

First, I write off an .afm file. It will have all the characters. On a PC, you can them use grep to search for all instance of, say, ".sc" in the afm file, and pipe them to another file. Working in that file, the columnar mode will quickly let you erase everything but the character names. Search & replace the returns with a space, and you now have a row. Copy the row, and search & delete the .sc (or .scmp or whatever). You now have a second row with the same order as the first. Copy that row, and apply a lower case" routine to the third row.

You now have three rows, one with all the small cap characters, and matching rows with the caps & lower case. Each to become a class. The only potential problem I'm aware of is the dotted cap I and small cap "I" for Turkish. Likely you could come across others, in some languages. But since you started with only the small caps, the problems will be minimal.

A similar search of the .afm should work for you stylistic variants, which you will have named ".alt" or ".alt01" ".alt02" etc. A sort may not be needed, but a text editor that will do that can be handy.

etc.

If I'm making a few changes to a font, I trust myself to the new add glyph names to the end of the class row. If there are a lot of changes, I write off a new .afm & do the construction work again. It doesn't take long.

I do something a bit different with the numbers; each kind of 0-9 has its own row. Then other thing also switched with numbers, (dollarsign, plus, minus, divide, etc. etc. for lining versus oldstyle) has it's own row, as does comma, period if I've made ones up for tabular numbers. Here, the splitting into separate rows makes things easier when you have to find things (read: fix problems).

On purpose, I'm not efficient with classes. I'll make more than are needed, so I as a human can find things & work on them. For example, I make up separate classes for the features tnum, pnum, onum and lnum. Each feature having 2 classes e.g., -- tnumb1 and tnumb2 as well as pnum1 and pnum2. The features programming doesn't need this -- but it is easier for me as an older human being (so I claim) to keep track of things. A real programmer would likely object to this wastefulness, and if you're careful, you can use fewer classes & maybe save some space in the file. Not my biggest problem.

But enough -- if this is the sort of thing you're interested in, you get the idea. If not, sorry to waste your time.

That's helpful, thanks Charles!