Opentype implementation

I've been diving into the FiraCode OpenType updates in preparation to update Cascadia Code's support, and was surprised to find that you'd switched all of the LIG substitutions for glyph-specific .spacer substitutions. And I haven't been able to figure out exactly why... Is there a specific reason? Personally, I'd rather not include a set of empty glyphs in the font when a single one is sufficient.

Second, I wanted to propose an alternate way of building the OpenType. At current, you are using backwards-looking rules that are implemented only for a given ligature. I think it would make sense to build them as forward looking, where one ligature replaces another. For example:

lookup less_bar {
  ignore sub less less' bar;
  ignore sub less' bar bar bar bar;
  ignore sub less' bar bar greater;
  sub less_bar.liga bar'  by LIG;
  sub less'         bar   by less_bar.liga;
} less_bar;

lookup less_bar_bar {
  sub less_bar_bar.liga LIG   bar'  by LIG;
  sub less_bar.liga'    LIG   bar   by less_bar_bar.liga;
} less_bar_bar;

In this example, less bar is replaced by less bar bar, rather than having a ligature specifically related to less bar and one specifically related to less bar bar. That allows us to dump a bunch of duplicate ignore statements to avoid the ligature from showing up as they're already being handled in less bar. The same code in FiraCode is:

lookup less_bar_bar {
  ignore sub less less' bar bar;
  ignore sub less' bar bar bar;
  ignore sub less' bar bar greater;
  sub less.spacer bar.spacer bar' by less_bar_bar.liga;
  sub less.spacer bar'       bar  by bar.spacer;
  sub less'       bar        bar  by less.spacer;
} less_bar_bar;

lookup less_bar {
  ignore sub less less' bar;
  ignore sub less' bar bar;
  sub less.spacer bar' by less_bar.liga;
  sub less'       bar  by less.spacer;
} less_bar;

As you can see, for these two lookups my approach has a savings of 3 lines of code, which should help with performance. And as far as I can tell, this approach also does not require the use of glyph-specific spacing glyphs.

If you're interested, I can provide you with the updated calt feature for this approach once I finish testing all the various use cases :).

Start by locating the current OpenType/calt feature generation and compare it with the FiraCode examples in the issue. Done would require an agreed decision on spacer glyphs and lookup direction, followed by validation across the mentioned ligature cases; no file or test is named.