Feature request: allow designspace files to control both rvrn & rclt, rather than forcing an either/or option

Currently, the rules element in a designspace must either make all substitutions before or after all other opentype feature substitutions. As @anthrotype explained it in https://github.com/fonttools/fonttools/issues/2040:

the rules in rvrn are processed first before any others, that’s how rvrn works. You should add processing="last" attribute to your <rules> element, this will make fonttools use a different feature tag (rclt) that respects the lookup order and will be applied last.

In that issue, the conclusion presented by @ctrlcctrlv is:

it seems strange that either all the rules must be processed last or none of the rules must be; unless there can be multiple <rules>? 🤔 But designspaceLib doesn’t support that

@justvanrossum responded with:

What .designspace supports is a high level simplification of what is theoretically possible with FeatureVariations, based on use cases we were aware of at the time. While what you suggest is possible, it would make everything a lot more complex.

Do you have a specific use case in mind where this could be handy?

I agree with @ctrlcctrlv, and in respond to Just’s question, I do have a use case:

In Recursive (as of dc36c9e), there is a relatively complex set of rules to activate cursive italics & mono or sans-specific glyphs at various axis locations. Many of these glyph substitutions are then used in logic by other OT features, so by now it would very likely be disruptive to the family to now change the rules with processing="last".

But, I am now trying to make arbitrary fractions possible, where the fraction bar is split in the default proportional/“Sans” styles (MONO < 0.5) but solid in the monospaced/“Mono” styles (MONO >= 0.5).

The intent is for the default to use fraction.split, and the mono to use fraction.

Thisfrac feature relies on detecting the slash and subbing it for a fraction.split (plus subbing in numerators/denominators for numbers).

But because rvrn happens first, it requires a workaround for frac to work afterwards. The font has to have a slash.split glyph which is subbed in by rvrn rules, so the frac logic can be basically sub [fraction.split fraction] by [slash.split slash]. And unfortunately, right now adding the extra glyph is breaking the static build for mysterious reasons which are still being determined. Ironically, the sub with the slash.split seems to be throwing the Recursive build for a recursive loop. 😅 Probably, that extra glyph needs to be decomposed… But in any case, you can probably see how this becomes a hacky workaround, and requires extra/redundant glyphs to be added to fonts.

If it were possible to control both rvrn and rclt via a designspace, this logic would be much simpler to set up, and designers would have a helpful extra bit of flexibility to decide when an axis-based substitution should happen, relative to other features.

Without that flexibility, it is now necessary to either have to keep the otherwise-unnecessary slash.split & debug the build, or else overhaul the whole set of substitution logic to allow rclt (which may or may not be possible with the current system of features).

So, this may best be summarized as:

Question: When does a designspace need to be able to control both rvrn & rclt? Answer: It needs it when it needs it 😄

I suspect this will become more necessary as more complex variable font projects are made. Once you get 99% of your gsub working with rules processing first, it is really painful to run into this problem at the last 1%.

How might this look in a designspace file?

I see three main possibilities:

1. My preference: processing="last" could be placed in a <rule> element, so the designspace would continue to only have a single rules element with multiple rules inside.
2. Alternatively, a user could have multiple <rules> elements, e.g. it would be fine to have both <rules> and <rules processing="last"> in one designspace.
3. A less attractive option: processing=last could conceivably even make sense at the individual sub element level, too. However, I feel like this wouldn’t be helpful, as it would encourage users to mix up rvrn and rclt subs, without a very clear benefit.

Of course, I realize that if Just says “it would make everything a lot more complex” to implement this, it is probably beyond my current understanding just how much complexity it might add. But, I do think there are a good number of scenarios in which people would appreciate the flexibility, so I wanted to cite one such case here. Thanks!

[juandelperal]

Thanks @arrowtype for filling this issue, and @justvanrossum for the deep explanation. I just wanted to add my 2 cents here: even though life is easier with rules last, at this time Adobe doesn’t seems to support rclt, so if your fonts happens to be “adobe users oriented”, you might be in problems. I added some tests in https://github.com/fonttools/fonttools/issues/2079

[anthrotype]

note I was referring to calt + rclt (both applied last, only the former working in indesign), not both rvrn + rclt (first and last) which don’t make much sense to me