[varLib.featureVar] Need to be able to generate 'rclt' and/or 'rlig'

[justvanrossum]

'rvrn' has some serious limitations, as seen in #1371 and discussed on the OpenType mailing list.

@behdad wrote in that discussion:

Can we agree to change description of either 'rclt' or 'rlig' to be the global feature that should be used for whatever font designer wants, GSUB and GPOS?

So, while the spec would need to be edited to reflect this suggestion, the documented behavior of 'rclt' and 'rlig' are suitable for our needs, and fontTools.varLib.featureVars should be extended to make this possible.

Ideally, this should also trickle up to designspaceLib, at least as an option.

[arrowtype]

Just adding that I would appreciate this change.

I am trying to implement "code ligatures" in a font, in a way that gives the end user better control over when code ligatures are applied. (Current code ligature fonts like Hasklig and Fira Code use calt, which tends to be active by default, and is therefore not good for a multi-purpose font.)

So, one thought of how to achieve this was to:

1. Make ligatures that don't look like ligatures – just two components. E.g. /equal_equal_equal.no_lig
2. Make ligatures that do look like ligatures, E.g. /equal_equal_equal.code
3. Use a calt feature (or possibly liga feature) to do looks for applying /equal_equal_equal.no_lig
4. Use designspace rules to swap from /equal_equal_equal.no_lig to /equal_equal_equal.code when a user turns up the CODE axis.

(Sidenote: yes, this is a bit hacky, and my preferred option is to use dlig, but this feature isn't currently supported by most of the software my font will depend on, whereas calt and axes/instances are.)

To make this CODE axis work, I have to create a glyph like /equal.precode, and swap to that in my axis rules, and then use /equal.precode in the lookup for calt. So, it adds another extra glyph and an extra layer of logical complexity to the feature. It's not impossible, but definitely not ideal.

My use-case is probably somewhat silly. Obviously, it's much more likely that this issue will bite people who wish to make use of conditional rules for connected scripts, (I think) especially in scripts like Arabic.

[khaledhosny]

Instead of having a variable access that is not variable, why not use dlig feature for off-by-default ligature which is its spec‘d behavior?

[arrowtype]

@khaledhosny that's mostly my preference, but there are pros and cons to either approach. I happened to make a slide show about this earlier in the week:

https://docs.google.com/presentation/d/11POJKckoGBhDk1kyQu3DC1tNUNJWwqF2FigIV6Tfdwo/edit?usp=sharing

[justvanrossum]

Fixed by d96c92f