skef

Fair enough - this idea is at the level of damage control. If we don't do something better soon, I think it's preferable to add this, if there is something...

Interesting. You need the "original" feature in order to have a featureIndex to substitute for (and to match the script and language system, but that could just contain any lookups...

OK, one hole: This design doesn't follow the Microsoft/Apple convention of preserving the behavior of the default instance in a context that doesn't understand variable fonts. But maybe the group...

OK, suppose we do want to preserve that behavior for the sake of consistency. Then: 1. Rather than have the original feature contain the "common" entries, just have it represent...

Thinking about this a bit more, the change from terminating at the first matching element (either "globally" or per-feature-index) to continuing means that what I described as the "logical" analysis...

> If I understand you correctly, negation should be easy if we just say if `filterRangeMinValue` is greater than `filterRangeMaxValue` then the condition is negated. Ah, that's clever. So if...

> "else" sounds good to me. In that case I suppose we would rev the major version on the FeatureVariations table and specify that that version has a FeatureVariationRecord something...

@behdad Do you think people will care if you can change the feature parameters by position with this mechanism or would that be so esoteric a need that we could...

I've been playing around with breaking this sketch down into subtables and records. One (tentative) decision I made is that with the move away from terminating at first match, I...

@Lorp Even if most implementations that *have* variable font support are processing the variable-font-specific tables at the default location, there's still the question of allowing the default location to render...