harfbuzz / boring-expansion-spec

Better-Engineered Font Formats; Part 1. Boring Expansion
79 stars 8 forks source link

beyond 'rvrn'? #133

Open BlackFoundry opened 7 months ago

BlackFoundry commented 7 months ago

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?

https://github.com/harfbuzz/boring-expansion-spec/assets/13123463/2a6e54a1-c640-4f9b-88d8-73fb0456bc75

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 https://github.com/harfbuzz/boring-expansion-spec/issues/94#issuecomment-1608007111 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 commented 7 months ago

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 commented 7 months ago

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

kenmcd commented 7 months ago

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.