Maybe the OpenType code from Adobe Garamond Pro is trying to reference characters your font is missing?

Yeah, could totally be the case: along with some of the exact glyph names.
Once I just tried some basic ligatures. Seemed pretty standard to try: "when f f then f_f" etc. But that didn't go through.
Some of the Robofab jive seems like it could work but its a little over my head and a bit unnecessary since its mostly available through FontLab options.

FontForge does it. FF generates necessary (empty) slots so there are no problems with missing glyphs.

Don't start with OpenType features by using a big feature file ripped from a complex font. Make your own feature file, adding features and relevant classes one at a time, testing each one as you go. But if you generate test fonts directly into the Adobe application fonts folder it's a pretty quick process.

Also, Adobe has provided some great documentation in the form of the OpenType Feature File Specification.

FF generates necessary (empty) slots so there are no problems with missing glyphs.

I'm fail to see how generating fonts with empty characters just to make bad code compile is better than refusing to compile the bad code in the first place.

Thanks for the comment about ripping it bit by bit. That might take time but it sounds like it will just plain work its tested as I'm going. I'll post again if I get any errors or stumbling blocks doing that.

Once I just tried some basic ligatures. Seemed pretty standard to try: "when f f then f_f" etc. But that didn't go through.

This isn't valid OpenType syntax. You might want to brush up on the correct syntax for .fea files at http://www.adobe.com/devnet/opentype/afdko/topic_feature_file_syntax.html.

André

"I'm fail to see how generating fonts with empty characters just to make bad code compile is better than refusing to compile the bad code in the first place."
1. I made a Roman font, ca 1500 glyphs with a lot of OT features (all mine from a to z)
2. I made a Bold font with the same glyph coverage but f_f ligature (by accident)
3. I merged the .fea file from my Roman
4. My new Bold has one empty slot named "f_f" so I am able to fill it and receive good, fully working font.
I think that makes more sense than receiving error, after all my code is good.
(I wish FF send a warning in that case)

thank you all for contributing. for the record, one of my glyphs was incorrectly named: FB01 was titled "fi" rather than "f_i".
that one string broke the entire syntax.
Now I'm diving into small caps, etc.
Thanks again. I might post more questions in regards to other features as I experiment with them.

like:

feature smcp { # Small Caps
sub @lowercase by @smallcaps;
} smcp;

declares that @lowercase will act as small caps by the user. How do I properly name my lower case glyphs that "@lowercase" recognizes those unicode characters?

for instance, Arno Pro has:

feature c2sc { # Small Capitals From Capitals
# Latin
lookup c2sc18 {
sub @onum1 by @onum2;
} c2sc18;

with a bit more of language script that I chopped out but still, how does this font recognize "onum1" by "onum2" — its not declared in any glyph name I see.
(does that make sense?)

Since you've got the demo version of FontLab, I suggest you read the section of the manual called 'OpenType Fonts' (i.e. the section starting on page 823 if you're using the manual from 5.0.4).

André

Feature code is compiled when an OTF is created, so the code you're seeing for Arno Pro has been decompiled by FontLab-- probably not the best model from which to learn. The FreeFontPro VFB that comes with FontLab would make for a better practical example.

Names preceded by '@' are classes, which can be defined in FontLab's Classes panel, or by declaring them in the lower part of the OpenType panel.

gargoyle, that explains a lot. I've known all these little elements but I've had the hardest time connecting the dots.
I'm knee deep in it all now. As I said, my glyphs are all designed, it was just the features I wanted.
Now its all coming together.
Thanks again!

"onum1" by "onum2"

is recognized because of class declarations where "onum1" might be the default figures and onum2 wold be the oldstle figures.

Your feature code would use the @ sign to indicate a class, as in: sub @onum1 by @onum2;

The names you input for classes as you design the font are most often swapped out by the software as it outputs your OTF file. To test this, design a font with odd class names and then output it as an otf. Then open the otf inFontLab and look at the OT code. You will see that your class names have been mapped to other ones.