[feaLib] handling of mixed single and multiple or ligature substitutions

If I have a feature like this:

feature isol {
 sub a by A;
 sub b by B C;
} isol;

feaLib will generate two lookups, a single substitution lookup and a multiple substitution one. But IMO it should have been a single multiple substitution lookup, as the first rule can be seen as a multiple substitution lookup with just one replacement glyph. The same happens when mixing single substitutions with ligature substitutions.

In many of my fonts this results in 10s of lookups which can slow the OpenType layout processing in some implementations. It does not help that the feature syntax does not provide any way to make this explicit, since the three different substitution subtypes use the same syntax.

It gets even worse with named lookups, a lookup like this will not even compile:

lookup isol0 {
 sub a by A;
 sub b by B C;
} isol0;

FontForge used to handle this gracefully and guess the right lookup type in these situations. I didn’t check with FDK does here.

[khaledhosny]

I don’t see where is all the magic that is hidden from the user here:

feature foo {
sub a by A;
sub b by B A;
sub c by C;
sub d by D B A;
} foo;

The lookup above is clearly a multiple substitution lookup, with some entries substituting to a single glyph. There is no more magic here than FDK deciding to split this into 4 lookups behind the type designer’s back. IMO the fact that FDK does not support such multiple substitution lookups is a bug/limitation since it does not provide any other way to have such a perfectly legit OpenType lookup.

[miguelsousa]

The font designer doesn’t care how the substitution is done as long as it does exactly what they specify.

Some font designers do care, and not being informed that something was changed or implemented in a certain way behind the scenes can lead to a lot of frustration when differences arise between what the designer/developer expected from the code and what results they’re getting (on e.g. an app).

I’m all for un-complicating things that are simple, but I’m leery of tools that are too helpful because there will be times when they make the wrong assumptions/decisions and if the designer/developer grows accustomed to being shielded from understanding what and how the tool is doing for him/her, it will eventually become an unwieldy tool.