table GSUB, table GPOS and multiple FEA files

[twardoch]

I wonder if it might be sensible to, principally, allow multiple FEA files to be used, and to specify the behavior of tge compiler explicitly. For example, it's common in font development that multiple fonts share the same GSUB table but use different GPOS tables. The definition of additional tables via FEA typically is per-font.

What I'm thinking about is that perhaps FEA could be extended with

table GSUB { 
   ... feature definitions strictly only for GSUB 
} GSUB;

table GPOS { 
   ... feature definitions strictly only for GSUB 
} GPOS;

If the table keyword occurs in a FEA file, the compiler would not attempt to overwrite other existing tables. Specifically, if table GSUB is used, the compiler would keep GPOS intact, and if table GPOS is used, the compiler would not touch the existing GSUB.

Right now, I think the behavior is a bit undefined. It's hard to say what a tool like makeOTF should do if a FEA only happens to have GPOS-related feature definitions, or only GSUB-related feature definitions, it's only a BASE table ovverride, and a FEA file is compiled into an existing OpenType font — what should happen to the existing GSUB and GPOS tables?

[twardoch]

This might be helpful in cases like #176

[twardoch]

Further, makeOTF could be extended to allow multiple FEA files in -ff, and of course one would be able to run the tool multiple times, each time supplying a different FEA file.

I know that we have the include statement, but it's not always practical to use it.

For example, when building variable fonts, one may want to first build a static font with GSUB, STAT and GDEF only, and then use code such as varLib to "merge" other masters and their GPOS tables. Because this is complex, creation of GPOS may happen via a different tool. But another scenario could be that GSUB is added afterwards, for whatever reasons, or it's added to some subsetted font etc.

[twardoch]

I think if table GSUB or table GPOS are used, then only other table blocks or the anon blocks should be allowed on the top level. I.e. defining features, lookups, lamguagesystems, classes etc. outside of table GSUB and table GPOS would be then illegal.

[readroberts]

I don't immediately see the need for the new syntax. Specifying 'table GPOS' or 'table GSUB' is redundant, as the feature files rules require creating a GPOS or GSUB, or the table isn't created.I think the significant change is requiring that the feature file compiler ignore GPOS or GSUB rules if the table already exists, which can happen with or without the syntax change. Also adding this syntax suppresses a useful behavior. Right now, if a feature definition has both GPOS and GSUB rules, they can be defined in a single feature block. If we require specifying GSUB rules only within a table GPOS|GSUB block, then such features would need to be defined in two different places.

Without specific examples, my guess is also that deciding whether to keep or replace pre-existing GPOS|GSUB table would be more easily handled outside compilation of the feature file.