VS Code: behavior of "editor.fontLigatures" and "editor.fontVariations"?

Question

It has been possible to configure OpenType variations in "editor.fontLigatures" for a long time by now, but it's very limited. E.g., to configure the double-storey 'g' for the Iosevka font, one can add this to settings.json:

"editor.fontLigatures": "'cv32'"

This sets the cv32 parameter to 1. However, as far as I know it's not possible to specify the value, e.g. cv32=2 to get the double-storey-open variant. In 1.74 they added "editor.fontVariations", and promised that it would do the job like this:

"editor.fontVariations": "'ital' 0.5"

(See https://code.visualstudio.com/updates/v1_74) This does not seem to work. No OpenType parameters work here, there is no effect on font rendering. They do work in the old, limited way in fontLigatures.

What am I doing wrong? How are these two configuration parameters expected to work? Is it working for anyone, possibly with a different programming font?

Answer 1

These settings depend on fonts that support the capabilities they activate. From the VS Code doc'n:

// Configures font ligatures or font features. Can be either a boolean to enable/disable ligatures or a string for the value of the CSS 'font-feature-settings' property.
"editor.fontLigatures": false,

If set to true, that will activate OpenType ligature features, if they are supported in the font. But if set to some other string like "'cv32'", that will activate that specific OpenType feature — the 'cv32' feature — if that is supported in the font.

Here's the description for the 'cv01' – 'cv99' features: https://learn.microsoft.com/en-us/typography/opentype/spec/features_ae#cv01-cv99

OpenType has different ligature features. The 'liga' (standard ligatures feature should normally be activated by default, though I don't know what Electron / VS Code does if .fontLigatures is false. Here are other ligature-related features:

• 'clig' (contextual ligatures)
• 'dlig' (discretionary ligatures)
• 'hlig' (historical ligatures)
• 'rlig' (required ligatures)

The 'clig' and 'dlig' features certainly ought to be activated or deactivated using boolean values for .fontLigatures. It probably would make sense to .fontLigatures to do the same for 'hlig'. But 'rlig' shouldn't be affected by .fontLigatures since the intent of the feature is for ligatures that are required for correct display of a script, such as the lam-alef ligature in Arabic.

Now let's look at what the VS Code documentation says regarding .fontVariations:

// Configures font variations. Can be either a boolean to enable/disable the translation from font-weight to font-variation-settings or a string for the value of the CSS 'font-variation-settings' property.
"editor.fontVariations": false,

The first part is not entirely clear, but I gather that a boolean value of true will cause a font-weight: nnn CSS property to be changed to the property font-variation-settings: "wght" nnn, which is functionally almost the same. (CSS cascading works differently, but otherwise they would do the same.)

But let's step back for a moment to explain what the font-variation-settings property does: it's intended specifically for use with OpenType variable fonts. A variable font has one or more axes of design variation, typically with continuous variation on each axis. Within the font, all variation axes are designated with a four-character tag, such as "wght" or "wdth". Many variable fonts support a weight axis (the tag for which is "wght"), but it's entirely up to a font designer what the axes of variation are. See https://v-fonts.com/ or https://www.axis-praxis.org/ for many examples of variable fonts and the axes they support.

So, back to `.fontVariations. First, let me explain the second usage,

or a string for the value of the CSS 'font-variation-settings' property

This could be used to set any variation on any axes of a variable font. For example,

"editor.fontVariations": "wdth" 93, "GRAD" 88

would translated into CSS properties

font-variation-settings: "wdth" 93, "GRAD" 88

Now back to .fontVariations: true: it's intended for use with a variable font that has a weight ("wght") axis. This doesn't seem particularly useful to me since (a) the only difference between CSS font-weight: 700 and font-variation-settings: "wght" 700 is that the latter doesn't cascade the same way, and (b) the same could be achieved by "editor.fontVariations": "wght" 700. But it appears to be another way to get the CSS property font-variation-settings: "wght" 700. (That, btw, will remove any other font-variation-settings, which is the different cascading behaviour I mentioned.)