Trouble with instancing Recursive's rvrn monospace character substitutions

[Shrinks99]

Hi there!

This started out as an issue in Slice that I'll ask here because they seem to use fontTools on the back end. :)

I'm trying to create a static version of Recursive set to specific values to be used as a brand asset. Recursive has a mono axis which swaps out certian glyphs with a .mono rvrn single substituion lookup (#248 in the font if you're gonna go looking for it). For most apps that I use that support variable fonts (Figma, Windows' font viewer, Inkscape) the instanced file created by fontforge with the varLib.instancer command will correctly result in the expected output. In tools like Affinity Designer that don't support variable fonts (and therefore don't support the rvrn OpenType function) this results in an instanced file where the non .mono suffix glyphs are used as if the file didn't have its mono axis set to 0.51+.

For reproducing this, the command I used was: fonttools varLib.instancer ./Recursive_VF_1.085.ttf MONO=0.52 CASL=0 slnt=0 CRSV=0 wght=715

Examples of Output Issues

Here's an example of what this looks like in Figma. The top text is stock variable Recursive, the bottom is an instanced version of the font. In Figma everything looks proper!

In Affinity Designer however using the same font file, the .mono glyphs are not being used, note the different r & l

The monospaced r & l shown above can't be accessed in Affinity Designer through a stylistic set or any other solution because it doesn't support the variable features Recurisve uses to swap the glyphs, even as a static cut. Is there a way to get fontTools to instance the file with the mono characters used for everything by default? Is there utility to including rvrn rules in a static cut of a typeface or should I file this as a bug report? Any help would be much appreciated :)

[jenskutilek]

Hm, the spec says:

Application of the 'rvrn' feature is mandatory in implementations that support OpenType Font Variations whenever a variable font is in use. The feature should be processed in any layout process that supports use of variations, even if other OpenType Layout processing is not supported.

After instancing, the font is not a variable font anymore, so it seems Affinity is not at fault here when they ignore the rvrn feature. varLib.instancer perhaps should drop the feature completely and change the affected glyph mapping the the cmap table.

As a workaround, you could change the glyph mapping after instancing by “freezing” the rvrn feature, e.g. with pyfeatfreeze.

[Shrinks99]

This was exactly the tool I needed to solve my issue! Thank you so much :)

As for my opinion, after going through this experience I would say that varLib.instancer would ideally take the rvrn rules into account when generating a single cut of a font? Would have saved me some trouble, that's for sure!

[anthrotype]

yes, the instancer simply copies the Feature record of the FeatureVariations that apply at the given location to the default FeatureList so that it will be always activated, with the assumption that a shaping engine will apply 'rvrn' when it seesn one; we don't change the FeatureTag. That could also be an option maybe, e.g. trying to rename "rvrn" to "ccmp" which is similarly applied early in shaping, and ought to be supported even when variations are not.

“freezing” the rvrn feature pyfeatfreeze

yes, if that works, I suggest you do that.

[behdad]

yes, if that works, I suggest you do that.

I think we should do that when instantiating.

[behdad]

I think we should do that when instantiating.

Or move its lookups to ccmp. That would be easier.