Designspace rules and feature variations are incompatible

[madig]

I didn't realize this before, and maybe I'm confused, but it seems that Designspace rules and feature variations are incompatible with each other, at least with the current implementation of varLib. Compiling a VF with DS rules and then calling addGSUBFeatureVariations either conflicts (when targeting the same feature as the rules) or overwrites what's there, if I understand correctly. Now that ufo2ft enables variable feature compilation by accident due to compiling identical feature files once and injecting them into the VF binary, it may need a RulesWriter of sort, that translates rules into variable features.

I don't understand the constraints around these enough yet, though. Like, how easy or hard is it to mix the generated feature variations for DS rules with custom variations you're writing?

[behdad]

I'm don't know feaLib much, but I do know how the DS rules are "merged". I can explain that if you want. Let me know if I can be of any help.

[anthrotype]

call to varLib.addGSUBFeatureVariations (which handles DS rules) should happen after the variable features (possibly containing conditionset blocks) have been compiled, because feaLib can only build new OTL tables from scratch, not update existing ones. I think we do that here:

ufo2ft/Lib/ufo2ft/_compilers/baseCompiler.py

Lines 470 to 471 in 779bbad

	# Add back feature variations, as the code above would overwrite them.
	varLib.addGSUBFeatureVariations(ttFont, designSpaceDoc)

Compiling a VF with DS rules and then calling addGSUBFeatureVariations either conflicts (when targeting the same feature as the rules)

can you post an example that reproduces these supposed conflicts?

[madig]

I'll try to make a repro soon.

I found that feaLib seems to call addFeatureVariationsRaw, which does not do any condition set overlap boxing, meaning that whatever condition sets you put into your var fea may clash with the condition sets generated by variable (DS rules) substitutions.

[madig]

Repro: aaaa.zip

The font got a wght and TRAK axis, with two variations:

1. Using rclt (Designspace rules, processing "last"), replace h by h.BRACKET.170 between wght=500 and 700.
2. When dlig is turned on and at TRAK=-50 (Dense), replace F and R by FR. Between wght=500 and 700, go on to replace FR by FR.wght.41. Outside TRAK=-50, dlig should do nothing.

The way the features are written, the condition sets interfere with each other. The following example uses the text "FRh", so "h" is the pi-like shape:

1. Outside TRAK=-50, h is correctly replaced:
2. At TRAK=-50, the dlig substitutions work correctly, but h is no longer correctly replaced:

This shows that existing condition sets are not taken into consideration when adding new feature variations. So, you have to either rely entirely on the var fea for all of it (and do the feature overlap boxing yourself, which would otherwise be done for you in addFeatureVariations for Designspace rules) or not use condition sets in your features.

[behdad]

The way the features are written, the condition sets interfere with each other.

I think feaLib should also call addFeatureVariations that does the box splitting. Am I missing something?

[madig]

That won't rewrite existing condition sets to not conflict with the new additions, no?

[behdad]

That won't rewrite existing condition sets to not conflict with the new additions, no?

No. For that we need more oomph.