OTVAR fonts: fontWeight/wght conversion fails

[MarcusSterz]

Issue Type: Bug

Expected: editor.fontWeight will reproduce the wght setting of the font, 1-1000.

Errors:

• Currently, only instance steps 400, 500, 600, 700, 800, 900 are supported, but steps outside this range (1-300 and 1000) should work to according to OT Spec for wght.
• All values are currently rounded to full hundreds, which defeats the purpose of variable fonts. For example, editor.fontWeight=650 will yield wght=700, but should yield wght=650.

VS Code version: Code 1.68.1 (30d9c6c, 2022-06-14T12:52:13.188Z)
OS version: Darwin x64 21.5.0
Restricted Mode: No

System Info

Item	Value
CPUs	Apple M1 (8 x 24)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: enabled video_encode: enabled webgl: enabled webgl2: enabled
Load (avg)	3, 36, 27
Memory (System)	16.00GB (0.03GB free)
Process Argv	--crash-reporter-id eacbd859-6fed-4522-ad9e-69485b4219d2
Screen Reader	no
VM	0%

Extensions: none

A/B Experiments

vsliv368:30146709
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
pythonvspyl392:30443607
vserr242:30382549
pythontb:30283811
vsjup518:30340749
pythonvspyt551cf:30345471
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscoreces:30445986
pythondataviewer:30285071
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593:30376534
vsc1dst:30438360
pythonvs932:30410667
wslgetstarted:30449410
vscscmwlcmt:30465135
cppdebug:30492333
vscaac:30438847
vsclangdc:30486549

[alexdima]

In the editor, we delegate all font rendering to the browser rendering engine, in this case, Chromium. It looks like the CSS font-weight would support any value between 1 and 1000 in modern browsers -- https://developer.mozilla.org/en-US/docs/Web/CSS/font-weight#variable_fonts . If Chromium doesn't implement the spec correctly, then please report as an issue directly to them at https://bugs.chromium.org/p/chromium/issues/list

[MarcusSterz]

It works fine, i.e., I can access any wght value 1-1000, in a simple HTML/CSS setup with the same font, in any browser, including Chrome on Mac and Edge on Windows. Just the editor.fontWeight setting misbehaves.

I didn't test it in VS Code on Windows though. It may be affecting only the Mac version?

I can provide sample files for recreating the bug if necessary.

[alexdima]

I have double checked, on our side, we just forward the value we're configured with to the CSS font-weight property. Here I'm setting "editor.fontWeight": 440:

@MarcusSterz VS Code Stable is on Chromium 98.0.4758.141 , which might be a bit behind compared to the latest Chromium/Edge. Given it is the same code-base, could you please also try at https://vscode.dev/ ?

[MarcusSterz]

I think I found the issue: For OTVARs, it should (additionally?) translate the setting into a font-variations-settings property for axis wght, not just the font-weight property. Like this:

font-variation-settings: "wght" 100;

Then it works

[chengluyu]

This is what I've been looking forward to for a long time. I made a prototype (the commit) and it works. Thanks to @MarcusSterz’s hint!

[chengluyu]

I'd like to implement this feature. Here's my pitch.

Like fontLigatures, VSCode should have an editor configuration item called fontVariations. It can be either a boolean to enable/disable font variations or a string for the value of the CSS font-variation-settings property.

• If fontVariations is true, we translate fontWeight to "font-variation-settings: 'wght' ${value}". We don't set font-weight CSS property because they seems conflicting with each other.

  The reason why we do like this is that font weight is a register variable axis. So if people are using a variable font (e.g. Cascade Code, Berkeley Mono) and they don't care about other variable axes, they can simply set this property to true to enable variable weights.

• If fontVariations is false, we translate fontWeigh to "font-weight: ${value}". This is identical to current behavior.

• If fontVariations is a string, we pass it as the value of font-variation-settings CSS property. In this case, font-weight is ignored.

@alexdima How do you think?

---

It just struck me that font-variation-settings does not apply to non-variable fallback fonts. I'm thinking…

[bebraw]

From user point of view, setting the additional CSS automatically for a typeface with variable weight would be great as then it would simply work. For this, maybe you would have to detect if weight is variable. A flag seems possible but I am not sure if it's needed.

Exposing fontVariations is probably a good idea anyway to give access to any other possible axes.

There's one additional consideration: how to adjust italics/bold specifically? You have the same problem there probably.

[chengluyu]

For this, maybe you would have to detect if weight is variable.

Do you mean detecting the font people are using is variable or not? That might be tricky.

[bebraw]

Do you mean detecting the font people are using is variable or not? That might be tricky.

Yup. If there's any access to font metadata, there might be something. Likely it's specified at standard level somehow.

[chengluyu]

I just complete the prototype (the commit) as the plan above. Here is a set of screenshots. Let me know your suggestions!

[chengluyu]

Yup. If there's any access to font metadata, there might be something. Likely it's specified at standard level somehow.

That would be nice. But now VSCode just passes font settings to Chromium, I think this kind of checks will introduce a lot of new dependencies to VSCode and Monaco editor, which might be not worth.

[bebraw]

That would be nice. But now VSCode just passes font settings to Chromium, I think this kind of checks will introduce a lot of new dependencies to VSCode and Monaco editor, which might be not worth.

Maybe one interesting option would be to apply the weight related CSS anyway and sort of discard the problem. The assumption here is that the CSS will work for non-variable fonts as well.