Make Cascadia Code a variable font w/ 6 named variations

[aaronbell]

Summary of the Pull Request

This major update adds a weight range to Cascadia Code. This font is now being built as a Variable Font, which enables users to select the perfect weight for their preference.

PR Checklist

• Closes Any plans for a lighter weight? (Or am I using it wrong?) #25 - weight axis added

• Closes Bug Report: parenthesis width changes when bold #43 - with weight addition, parenthesis width is preserved

• Closes Use better == symbol #284 - ligature now broken for easier recognition

• Closes Feature Request: Consider making it a Variable Font #90 - produced as a variable font

• Closes Feature Request: Provide more weights #128 - MORE WEIGHTS

• Closes Cascadia Mono shouldn't use contextual alternate for x #285 - contextual code removed

• CLA signed.

• Requires FONTLOG.txt to be updated

• I've discussed this with core contributors already.

##Detailed Summary
The weight range now extends from ExtraLight (200) to Bold (700), with the current Regular set at 500. As a variable font, OS / rendering engine support may vary. Users running Windows 10 and Windows Terminal will have access to the full range of font weights. Other applications may only have access to the named instances (ExtraLight / Semilight / Light / Regular / SemiBold / Bold) depending on inbuilt support.

Static instance OTFs are also provided. At current, static TTFs are not built in this update, but it is something we will consider in the future.

Before (if applicable) and After Images of the Character(s)

Validation Steps Performed

Variation implementation tested on Windows and Mac, font hinted and reviewed on high and low DPI devices.

[DHowett]

Okay, a straight-up build took 7 minutes without the static fonts. To put it in perspective, Terminal takes 18-30 minutes to build 😄
Since this isn't part of the CI, or since we can do a stripped down version of this for CI, I'm not worried about the build times at all.

[tuananh]

can't wait for the release <3

[aaronbell]

@DHowett You should try building with the static fonts. :D

[DHowett]

Here it is in our build pipeline with static + PL + mono 😄

It's pretty quick, all things considered!

[tuananh]

@DHowett where can I download the new build? There's no new release yet :(

[madig]

The Python toolchain is a damn snail (did you know that building the Google Noto fonts sequentially takes >24h?). I generate statics in parallel: https://gitlab.gnome.org/GNOME/cantarell-fonts/-/blob/master/scripts/make-static-fonts.py -- warning, will eat all your RAM on large amounts of instances. Also, all variable fonts can probably be generated in parallel with multiprocessing along the same lines.

[vuon9]

Hi, thanks for big effort in this improvement.

How Semilight works on Windows, please? I've tried in VSCode with Cascadia Code SemiLight Cascadia Code Regular SemiLight Cascadia Code Semilight but they didn't work. So confused because Cascadia Code ExtraLight and Cascadia Code Light actually work, SemiLight seems not similar as format of name?

On Mac, CascadiaCode-Regular_SemiLight works fine, but can't use it for Windows.

[aaronbell]

Oh that's interesting. Normally I'd suggest using VSCode's Font Weight setting, but I note that VSCode doesn't offer the ability to pick a font weight besides on the 100s (similar to how CSS is limited).

The issue here is that while the Opentype Spec lists 'commonly used' weights only at the 100s, any value is actually allowable. Unfortunately, both CSS and (it appears) VS Code limit the font weight options to the whole 100s following the 'commonly used' values. However, as SemiLight was left off of that original list, the common convention is to insert it at 350. This includes major Microsoft fonts such as Segoe UI Semilight.

As such, I unfortunately think this is an issue that VS Code will need to resolve, so I've filed a bug on their github. @DHowett, if there's someone you can talk to through your channels to push this above the line, that'd be great :)

[aaronbell]

BTW, it appears that there is an existing bug on this issue: microsoft/vscode#101467. I'd suggest heading over there and lending support to it so it can get more attention :).

This is definitely an issue that VSCode will need to implement.

[vuon9]

Thank you @aaronbell for giving me more information in this issue.

[IllusionMH]

FYI numeric values are supported for editor.fontWeight in latest Insiders ("editor.fontWeight": 350 is now valid, "350" as string will be ignored).
terminal.integrated.fontWeight is still in progress because it has external dependency on Xterm.js ("terminal.integrated.fontWeight": "350" (as string) currently shows warning but works as expected)