In answer to your first question, about the required characters, FontLab will add them automatically by default if they are absent. The reason they were missing in the fonts you mention is because they were not TT-based.

With regard to kerning classes, I think the important thing is to set them up in a way that makes the most sense to you. My own system is similar to what Adam describes, but I try to make the groupings easy to remember and avoid including glyphs with different ascender and descender attributes.

With classes, I set them up similar to your first example but using the theory of your second example whereas they aren't necessarilly letter dependent but shape dependent.

_e_left: e' eacute egrave o oacute ograve c ccaron ccedilla
_e_right: e' eacute egrave ae oe

This is just a quick example and I think like Mark said it comes down to personal preference and working yourself through a process that makes sense for you.

@Mark: Thanks. Yeah, being non TT-based would make them not conform to the TT specs, I suppose. :) I knew I had missed something!

Also, I went through the FLS5 manual again, and and found something I had overlooked in the "Font Header" section, under the TrueType Mapping Settings [cmap Table]:

"If the Automatically Add... option is on, then FontLab Studio will analyse the font and add characters that are necessary for complete font compatibility. In Windows only two characters are really necessary: the ".notdef" and "space" characters. On the Mac a couple additional characters are required: "CR" and "NULL". Note that FontLab Studio will generate these characters only if they do not exist in the font, so you can create them manually and control their appearance. We recommend leaving this option on, especially if you are developing Macintosh fonts."

So that clears that question up. Thanks a bunch.

Concerning classes, I agree that it is largely a matter of preference, and I would probably use the first example myself, but would still like to hear everyone's preferences and particular techniques; you never know what you may pick up from a casual comment.

Also, clarification on Karsten's "automatically 'merge' classes" comment above is something I am quite interested in.

Regards,
-Duncan

I follow the "like shape" model.

So I generally put c, d, e, o, q, ð and œ in the same class.
However, in a tightly-fitting style, d and q may be separated into their own class, if they aren't quite so round as the others.

Accented characters are trickier, sometimes I have ended up with three classes each for the variants of a, e, i and o.
In fact, I have on occasion kerned each i-accent character separately.

@Nick: Cool, thanks. That's the kind of thing I meant when I said 'you never know what you may pick up.' Separate classes for accented characters (and special treatment of i-accent characters) is something I probably would have never thought of.

@Mike Jarboe (et al.): So you generally keep your 'left' and 'right' shape classes separated? What about when you get overlapping content? Do you just accept the redundancy in the code and keep the shape classes separated, or do you keep them separate during production and then go back and 'merge' the identical content into the same class?

That's basically the heart of my inquiry; In order to keep the code as quick and clean as possible, is it acceptable to have redundancy in the [left/right] classes, or should the classes with identical content be merged whenever possible? (And is that a 'feature' in FLS5?)

I tend to be excessively fastidious with my coding, so I may be sweating about nothing here. I just always look for the most efficient way to craft my code (efficient for the parser that is), even if it means a lot more work on my part.

I also know that every typeface is treated differently, so I'm basically talking generalities, but any information is welcome.

Regards,
-Duncan

Not quite sure what you mean by "overlapping content", but please note that a glyph may only be referenced in the kerning classes once for the left side and once for the right side, or once in a class that applies to both.

Yep, I got that, Mark, but thanks for pointing it out. What I mean by 'overlapping content' is basically redundancy in the code:

_a_1st: a' aacute agrave adieresis
_a_2nd: a' aacute agrave adieresis
etc...

That can be 'grouped' into one class of the 'both sides' [left/right] variety:

_a: a' aacute agrave adieresis

I guess better phraseology would have helped. Sorry for the confusion.

If you have a class for the left and right that have the same exact glyphs, then go ahead and merge them into a single right/left class. However, doing so gives you less flexibility with regard to what can go in the class.

Right, hence my original question. And I'm merely asking for your guys' opinion on how you would handle it, not what is permissible - I'm pretty comfortable with the concept of classes.

To restate and clarify:

Assuming that left/right classes are kept separate during kerning, do you just accept the redundancy in the code and keep the shape classes separated when you generate the font, or do you keep them separate during production and then go back and 'merge' the identical content into the same class when you are done kerning? (And is that a 'feature' in FLS5?)

I apologize if I sound argumentative, that is not my intent. I'm just curious how you folks here, who have infinitely more experience than I, go about dealing with this little peculiarity. And again, sorry for the confusion.

Well, I don't think I would want to "merge" things after I've done kerning. It sounds like extra work. I try to plan out the best strategy for the kerning classes (usually based on identical or closely similar shapes) before I start kerning and then stick with it. The classes depend a lot on the genre of the type design.

(That said, I've been using Metrics Machine to do the kerning in my more recent designs. In that program, there are only left and right groups (no groups with both), and there are no "key" glyphs.)

Ditto what Mark wrote above. Well, except that I haven't used Metrics Machine, myself.

Sorry for not responding earlier.

Mark Simonson wrote:
If you have a class for the left and right that have the same exact glyphs, then go ahead and merge them into a single right/left class. However, doing so gives you less flexibility with regard to what can go in the class.

I completely agree. This is why, in my post which you cite, I wrote:
... and upon generating fonts I automatically 'merge' classes with identical content into a single class.

The important part is "upon generating fonts". Merging happens outside of the vfb and will leave the vfb's original leftside and rightside classes intact.
It is not a feature of FLS5 but part of my own font generation method/automatism. When doing Litteratra which has a lot of kerning and classes I noticed that AFDKO would produce a slightly smaller GPOS table if classes are merged. I should test this again with newer versions of AFDKO. Most of the time merging is mere cosmetics and not worth the effort.

So if you keep leftside and rightside classes separate this is fine and makes it easier to extend the glyph set later. In so far, as Mr Simonson said.

* * *

As to the first four glyphs, the spec recommends them only for TT-OTFs (i.e. OTFs with TT-outlines, in a 'glyf' table), not for CFF-OTFs (or PS-OTFs in Adam's terminology, i.e. OTFs with PS-outlines, in a 'CFF' table). Adobe's fonts are CFF-OTFs, so they are not affected by the recommendation.
With CFF-OTFs, the first glyph is expected to be '.notdef', usually followed by 'space'.

If you make TT-OTFs, it may be better to add the first four glyphs manually rather than relying on FLS5. Then you have a chance to adjust their widths. Advance width of 'CR' usually is the same as with 'space'; '.null'/'NUL' has an advance width of 0; and advance width of '.notdef' is up to you.

Best wishes, Karsten

I use shape based classes plus diacritics. I later end up making "exceptions" with some of the diacritic combinations that crash,

I like to be thorough too. I've set up classes for every letter, per side (plus sets for punctuation and other glyphs), then broken them out into matching visual sets, while turning off redundant individual classes. This way classes can be brought into new designs and adjusted as necessary.

For example, I can group all of my Es in to one for being on the right side, then drag them to be with the class "_BDEFHIKLNPR_R" to kern all of them the same, because the left side is exactly the same on all of these letters in my design. By keeping the individual classes too, I can always just go back if there are instances that need specific attention. VWY are a class, vwy are a class, but when working with this set as small caps I need vw and then y.

@all: Great information, thank you very much for your thoughts. You are all brilliant, and deserve the highest praise.

@Mark Simonson: Thank you for the response, and for taking the time to help. I tend to ask the most peculiar questions in the most insufferable way possible. Your patience is most valued.

@Stickley: Looks like I've found a kindred spirit in relation to coding. :) Thanks for the example. Lots of good stuff there.

@Karsten: Thanks for the clarification on the statement from your other post, and all the other great stuff. By the bye, where did you acquire the information about the advance width of 'CR', et al.? Years in the business? I looked all over and found nothing but the Microsoft Typography Character design standards, which didn't expand on the subject.

Concerning kerning classes, it's good to know that in a font with a moderately sized GPOS table, fussing about merging the left/right classes is probably superfluous. And making it easier to extend the glyph set later, if required, is something that I need to remember, for many different reasons, not just this.

Regards,
-Duncan

In this case, inspecting fonts.

I wrote:

... and upon generating fonts I automatically 'merge' classes with identical content into a single class.

Tested again. Merging left/right classes does not make a difference.