Problem compiling “GSUB” table

after adding more than 1601 ligatures, I am unable to compile the features and I get the following error message. below 1601 ligatures, everything works fine and I am able to compile and export the font.
Screen Shot 2022-10-29 at 10.39.25 AM

is there a solution for this? (I tried use extension kerning parameter, but it did not work)

Lookups can only have a certain size. There are some things you can do to avoid that limit like outing the ligatures into several lookups and using extension lookups to fit them in.
To have a subtable overflow in GSUB features is quite rare. Can you send me the file that I can find the best was to fit it in?

The ligature substitution chains are very long. For long ligatures like ‘xxx-yyy-zzz’, better have two lookups in liga:

  1. One that only does sub x x x by xxx; and the same for yyy and zzz.
  2. A second lookup for ligating the parts, sub xxx hyphen yyy by xxxyyy; etc.

It will also reduce your code significantly, and make it easier to handle.

thank you so much!

one question though, will reducing the name of ligature itself (the text that comes after by, so in this example is ‘xxxyyy’) make a difference as well?

The glyph names are not stored in the lookups. Only glyph indexes are.

alright I got you, what about removing some of the hyphens? does that have any effect?

Hyphens, underscores, etc. are part of the glyph name and glyph names are not used in the font file for OpenType features. So, all the glyph names that you write in the feature code are converted to glyph indices (glyph ids, numbers) in the exported font file. Thus, the length of names in feature code does not matter for the file size of the exported font file.

What is limit for how many entries a lookup can have?

There is no way to tell a number of entries. The internal structure is more complicated and it depends on many different bits and pieces how the data is stored and compressed.