Underline position and thickness metrics are not correct

[simast]

Environment

Cascadia Code version number: 2009.22
Application (with version) used to display text: Windows Terminal 1.4.3243.0
OS platform and version: Windows 10
Screen resolution (i.e. 220dpi):  -

Steps to reproduce

Inspect underline thickness and position with larger font sizes.

Expected behavior

I expect underline to be more thick with larger font sizes (if you compare to other fonts).

Actual behavior

Seems like underline thickness is always reported around 1px. I suspect that underline position metric is also off (should probably be offset by more pixels with larger font sizes, as right now this seem to be constant value no matter the size).

Screenshot showing the issue in Windows Terminal (with font size set to 40px):

[kenmcd]

Text editors or DTP apps which support font styles etc. will typically override the underline settings in a font and instead replace it with a horizontal rule under the baseline.
This avoids issues with all the wacko underline settings in some fonts and provides more control. Found one recently which had an underline thickness setting of 0 (zero), so no underline appeared at all. This is why editors simply use their own settings.
Cascadia Code has the same underline settings in all fonts.
So if the editor actually uses them an underline will be even across all the weights.
Some fonts have different underline settings in different weights.
In less advanced editors this results in broken underlines with different weights on one line.
So more advanced editor apps override the settings for a better one-size rule.
In LibreOffice it sets a weight on the rule based on the starting font weight.
No control other than that.
In advanced DTP apps like InDesign you have control over both the thickness and the vertical placement of the underline rule.

Back to your issue ...
Most likely Windows Terminal is setting the thickness and the placement of the underline rule.
You can check this by trying a different font.
My guess is you will end up with the same underline with any font selected.
Most code editors are not going to be used set at a 40 pixels font size.
So they selected an underline thickness of 1 pixel which is more appropriate for an expected font size setting of say 10-13 pixels, and they work around any odd hinting issues.

So not likely a Cascadia Code font issue. Just the way smarter editor apps work with underlines.

[simast]

I did try other fonts with Windows Terminal, just for comparison:

Courier New:

Consolas:

Cascadia Mono:

It seems Windows Terminal now strictly relies on those metrics to draw underlines. I was not aware some fonts don't fill this properly or leave values at 0 as you mentioned. If that's the case then it makes sense for renderers to somehow ignore those metrics or try to figure them in other ways. But it is probably not a hard fix to fill this in Cascadia Code for better compatibility.

[kenmcd]

Yes, you are right.
I compared the underline metrics on those three fonts and the settings directly correspond to your image.
So the underline settings in Cascadia Code would need to be changed to affect your issue.

[kenmcd]

Compared the underline settings in Cascadia Code, Fira Code, Courier New, Source Code Pro, JetBrains Mono, and Consolas.
Cascadia Code underlines are less than half the thickness of Source Code Pro and JetBrains Mono.
But close to Fira Code.

[aaronbell]

Per issue #428, use of the MVAR table (required for the solution to this issue in the Variable font) can cause problems. As such, I will have to roll-back the fix for this issue until the MVAR has better coverage cross-platform.

I will increase the overall weight of the underline so it isn't quite so thin, but it won't be weight-responsive :(