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?
2
Answers
There is info in OTVAR fonts: fontWeight/wght conversion fails on how this setting works.
But near the end of that issue it is noted that the Chromium engine that vscode uses isn’t rendering this correctly on Windows if I read that issue correctly.
These settings depend on fonts that support the capabilities they activate. From the VS Code doc’n:
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:
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:
The first part is not entirely clear, but I gather that a boolean value of
truewill 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,
This could be used to set any variation on any axes of a variable font. For example,
would translated into CSS properties
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 CSSfont-weight: 700andfont-variation-settings: "wght" 700is 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 propertyfont-variation-settings: "wght" 700. (That, btw, will remove any other font-variation-settings, which is the different cascading behaviour I mentioned.)