beyond 'rvrn'?

[BlackFoundry]

The 'rvrn' feature is used for one to one glyph substitution at defined design-space threshold.
https://learn.microsoft.com/en-us/typography/opentype/spec/features_pt#tag-rvrn

This is only enabling GSUB type 1 lookups.

Wouldn't it be useful to to enable at least GSUB type 4 lookups for design-space conditional ligatures?
Or even enable all type of GSUB lookups with a more generalized mechanism?

rvrn.mov

In this example the trick was to first do an 'invisible' ligature at the whole font level:

feature liga {
	sub g h by g_h;
} liga;

then use a conditional Required Variation Alternates:

<rules>
    <rule name="joining">
        <conditionset>
            <condition minimum="0" maximum="170" name="Breathe" />
        </conditionset>
        <sub name="g_h" with="g_h.lig"/>
    </rule>
</rules>

But ideally we would like to have access to the whole panel of GSUB lookups for conditional substitution rules.

I think that it is technically possible, and there are many use cases, perhaps even more in scripts such as Arabic or Indics.

Remain the question of defining a syntax for it (in the .designspace document?). Or perhaps there should be simple ways for designers to implements such things in a font editor?

[behdad]

But ideally we would like to have access to the whole panel of GSUB lookups for conditional substitution rules.

I think that it is technically possible, and there are many use cases, perhaps even more in scripts such as Arabic or Indics.

Yes, it's technically possible in the spec already.

Remain the question of defining a syntax for it (in the .designspace document?). Or perhaps there should be simple ways for designers to implements such things in a font editor?

So yeah, remains either a .designspace document, or better, the variable-aware .fea syntax that @simoncozens has introduced.

I don't think there's any work to be done in the spec.

[simoncozens]

Right, there's no work to be done on the OpenType side. You can already use FeatureVariations to substitute a GSUB lookup for different parts of the designspace in any feature you like. The OT format supports it just fine; you just need your font authoring software to create the appropriate FeatureVariation tables. "Feature variations are GSUB1 lookups inside rvrn" was a kind of weird limitation on top of the FeatureVariations mechanism - I don't know if Microsoft's shaper implements FeatureVariation support for other named features, but I kind of also don't really care. The spec says that you can do this in other features, so if MS doesn't, that's a bug in their software, not in the spec.

But as you say there are tooling issues as well. Designspace also leant into that same weird "single substitutions in one feature" limitation as well. I've used variable feature syntax to add variations to other features, and it works really well.

[anthrotype]

using variable feature syntax should already be supported as of ufo2ft v3, please give it a try and let us know if it doesn't work as you'd expect

[justvanrossum]

Designspace also leant into that same weird "single substitutions in one feature" limitation as well.

FWIW, that was a very conscious choice.

The question was, do we add a usable subset of the Feature Variations functionality (the subset that that most people will need), that is relatively easy to explain, easy to author, and fits the general style of the .designspace format, or are we going to make this hyper general but then it likely won't happen (from us) because this is too much and too out of scope for .designspace? It was a pragmatic choice to have something "soon" and workable, rather than something perfect and complete.

I'm glad you stepped up and made a general solution by extending .fea. I think that's where it belongs and where it shines. (And/or in other languages that serve as text input for OpenType layout features.)

[BlackFoundry]

I've used variable feature syntax to add variations to other features, and it works really well.

Sounds great! Can you show examples of how it works? How should it be implemented?

[simoncozens]

Can you show examples of how it works?

It's the same as the example in the variable features branch of the AFDKO spec:

conditionset heavy {
    wght 700 900;
} heavy;

variation rvrn heavy {
    lookup symbols_heavy;
} rvrn;

except that instead of rvrn you use a different feature. :-)

How should it be implemented?

I'm not sure I understand the question - do you mean how should it be implemented in a feature compiler? It already is implemented in fontTools and, I think, fea-rs, so you could look to the code of those for inspiration.

[anthrotype]

I think one notable difference between the designspaceLib rules and the conditionset/variation FEA blocks as implemented in fontTools.feaLib is that DS rules use internal design-space coordinates (the "output" of DS axes' maps), whereas FEA's conditionset currently uses external user-space coordinates (the "input" of DS axes' maps).
We discussed in #94 (comment) to add some suffix to the coordinates to allow user to specify whether to interpret them as user-space, design-space or normalized. I believe fea-rs even implemented that:

https://github.com/googlefonts/fontc/blob/7fd323038fa2f4977f019e1f6ba77965a1a1fcf5/fea-rs/src/parse/grammar/metrics.rs#L190-L208

[BlackFoundry]

Thanks @simoncozens for the example; but I am not able to find it on:
http://adobe-type-tools.github.io/afdko/OpenTypeFeatureFileSpecification.html
nor there:
https://github.com/adobe-type-tools/afdko/blob/spec-featurevar-syntax/docs/OpenTypeFeatureFileSpecification.md

not sure where to look at, can you help?

[BlackFoundry]

found it: https://github.com/adobe-type-tools/afdko/blob/spec-featurevar-syntax/docs/OpenTypeFeatureFileSpecification.md#4ei1-conditionset

[kenmcd]

I've used variable feature syntax to add variations to other features, and it works really well.

Could you point out some specific fonts please.
Would like to see it in use.
Thanks.