Monspace 1.1: VS Code prefers semiwide extralight for some reason

[adiabatic]

I suppose an easy fix would be to remove the extrawide and semilight variants of the fonts, but…

This is what fonts look like on my laptop running Sonoma, in the latest version of VS Code:

And this is what I get on my desktop, with all the old versions of Monaspace removed and the new ones copied from the otf folder in 1.1:

Is there an obvious fix to this, other than by taking out the wider and thinner font variants? VS Code only seems to give me a way to control weight (editor.fontWeight), not the condensed/expanded axis.

[adiabatic]

For what it's worth, the font selection is also widening the terminal font, even though the terminal font isn't on the thin side:

[adiabatic]

If you want to select the too-thin and too-wide variants to disable them in macOS, you can do that with a couple of Smart Collections in Font Book:

Then, right-click on each entry in the Collections area on the sidebar on the left and choose Deactivate fonts in Monaspaces {Light,Wide}.

[Finii]

Well, the reason can be in the naming. Lets see what is set:

$ fontforge ~/git/nerd-fonts/bin/scripts/name_parser/query_name MonaspaceKrypton-SemiWideLightItalic.otf
Examining 1 font files
======== MonaspaceKrypton-SemiWideLightItalic.otf ========
SFNT Fullname      ID 4     Monaspace Krypton SemiWide Light Italic
SFNT Family        ID 1     Monaspace Krypton SemiWide Light
SFNT SubFamily     ID 2     Italic
SFNT Pref Family   ID 16    Monaspace Krypton
SFNT Pref Styles   ID 17    SemiWide Light Italic
SFNT PS Name       ID 6     MonaspaceKrypton-SemiWideLightItalic
SFNT Compatible    ID 18    Monaspace Krypton SemiWide Light Italic
SFNT CID findfont  ID 20    -
SFNT WWS Family    ID 21    -
SFNT WWS SubFamily ID 22    -
PS fontname                 MonaspaceKrypton-SemiWideLightItalic
PS fullname                 Monaspace Krypton SemiWide Light Italic
PS familyname               Monaspace Krypton SemiWide Light
fondname                    None

Font grouping is done by

• ID 1 / 2 (classic RIBBI group, can only support Regular, Italic, Bold, and BoldItalic)
• ID 16 / 17 (expanded grouping)
• ID 21 / 22 (WWS grouping)

Some explanation is maybe in [1].

As we see above Monaspace has the Width in ID 17. That is usually not supported by application if I'm not mistaken.
Lots of fonts put the width axis instead into the Family (ID 16), which is then easier to select.

If they really want to support the widths axis the full WWS model should probably be used additionally.

[1] https://learn.microsoft.com/en-us/typography/opentype/spec/stat#alternate-font-family-models

[Finii]

Counterexample, they put the width part (Condensed here) in ID16, that is supported more widely:

Examining 1 font files
======== NotoSans_Condensed-ExtraLightItalic.ttf ========
SFNT Fullname      ID 4     Noto Sans Condensed ExtraLight Italic
SFNT Family        ID 1     Noto Sans Condensed ExtraLight
SFNT SubFamily     ID 2     Italic
SFNT Pref Family   ID 16    Noto Sans Condensed
SFNT Pref Styles   ID 17    ExtraLight Italic
SFNT PS Name       ID 6     NotoSansCondensed-ExtraLightItalic
SFNT Compatible    ID 18    -
SFNT CID findfont  ID 20    -
SFNT WWS Family    ID 21    -
SFNT WWS SubFamily ID 22    -
PS fontname                 NotoSansCondensed-ExtraLightItalic
PS fullname                 Noto Sans Condensed ExtraLight Italic
PS familyname               Noto Sans Condensed ExtraLight
fondname                    None

(These comments are of course no solution for the problem per se, but should be a hint for the Monaspace team)

[kenmcd]

I suppose an easy fix would be to remove the extrawide and semilight variants of the fonts, but…

This is what fonts look like on my laptop running Sonoma, in the latest version of VS Code:

And this is what I get on my desktop, with all the old versions of Monaspace removed and the new ones copied from the otf folder in 1.1:

Is there an obvious fix to this, other than by taking out the wider and thinner font variants? VS Code only seems to give me a way to control weight (editor.fontWeight), not the condensed/expanded axis.

Some of the fonts have the wrong usWeightClass setting in the OS2 table.
Monaspace Argon SemiWide ExtraLight is set to 400 which is the same as the Regular 400.
ExtraLight should be 200.
ExtraBold is also set to 400, and should be 800.
Same in the other families - Krypton, etc.
The application is probably getting confused by multiple fonts all being set to 400, and perhaps also name issues.
This will require the fonts being fixed before it has any chance of working properly.

[idan]

Investigating!

[rileycran]

Working on a fix for this, will update shortly! Thanks for spotting the metadata issue @Finii @kenmcd 🙏

[Finii]

Good find @kenmcd !

In fact the Nerd Font patcher complains about the font:

$ fontforge font-patcher --debug 2 monaspace-v1.100/fonts/otf/MonaspaceArgon-SemiWideExtraLight.otf 
Nerd Fonts Patcher v3.2.1-34 (4.14.3) (ff 20230101)
...
Done with Patch Sets, generating font...
WARNING: Possible problem with the weight metadata detected, check with --debug
DEBUG: Weight approximations: OS2/PS/Name: 400/400/200 (from 400/'Regular'/'ExtraLight')
...

(It was already the case with v1.000.)

Note that not only the OS2 weight is wrong, but also the PS weight, which all three should match somehow. Not that there are fixed rules how they all interact (*), but certainly you should not have the same weights for different weights ;-D

(*) There are some general agreements which number ranges match which weight names, but that is not fix and differs from font foundry to font foundry

What I commented on yesterday ... this is just my opinion.
And it directly contradicts the expectations voiced here:

• These fonts are unusable in modern IDEs and editors. #111 (comment)

There is some odd behavior with the semi-wide fonts showing up as a separate face

('Face' is probably used wrongly here, but it is clear what is meant.)

I usually prefer to have only all the weights on one selectable font family (group), and have the different widths (or whatever other axis there are) as different families, but as you see that varies.

Some ttx dump extracts:

(When I say "PS weight" I mean the weight name in the CFF table, see above)

Edit: Show version 1.100 in ttx instead of 1.000 😬

[Finii]

No comment ;-)

NAME table copyright (SFNT) has been set but not "PS" copyright.

Hmm, and while I look there, was the goal not to have isFixedPitch set?

• post.isFixedPitch #132

[idan]

Should be fixed in e6f6278! Thank you for the report 🥰

[floriancargoet]

@idan This does not appear to be fixed for me. I'm using 1.101 and when I set VSCode's fontWeight to 300, the text is suddenly very wide.

[rileycran]

@floriancargoet This is inline with an unexpected behavior that @idan and I noted recently, not entirely sure what is causing it but we're investigating. It seems to have something to do with VSCode being unsure of which 300 weight font to use, from the family (which width, in other words).

[floriancargoet]

Thank you for these details. Is there an issue I could subscribe to?

[rileycran]

@floriancargoet Also, can you please use the Monaspace private use unicode glyph () into your editor, to confirm you're seeing the correct fonts, and not a caching issue?

[floriancargoet]

It displays v1.101.

[kenmcd]

@idan This does not appear to be fixed for me. I'm using 1.101 and when I set VSCode's fontWeight to 300, the text is suddenly very wide.

I don't think you should use a weight setting with the static fonts.
Set the Font Family to: 'Monaspace Neon Light',
And set the Font Weight back to: normal
This appears to work for the normal text.

Or set the Font Family to the name of the variable font,
and then set the Font Weight (my guess).
How this interacts with the Font Variations is unknown
because there is no docs (that I could find).

Not sure how that affects the Bold and Italic text.
I think it (vscode) assumes you are going to have a normal RIBBI family.
But in your case there is not a style-linked "bold" font.
And I think I have seen a way to set the Bold and the Italic manually.
Maybe it is all handled in the CSS.
Dunno. Their documentation is lacking.

[floriancargoet]

There's a lot I don't understand in your comment (I know very little about the technical details of fonts) but I've set the VSCode font to 'Monaspace Neon Light', with the default weight and it displays correctly. Thanks.

[kenmcd]

There's a lot I don't understand in your comment (I know very little about the technical details of fonts) but I've set the VSCode font to 'Monaspace Neon Light', with the default weight and it displays correctly. Thanks.

After looking at this a bit more it appears VSCode does need a standard Regular/Italic/Bold/BoldItalic font family to work as expected.
Depending on the code language and the theme used, some code blocks will be Bold and some will be Italic.
So the style-linking matters.
Your Light is not linked to a "bold" which it can select.
VSCode apparently does create fake bold and fake italic when they do not exist for that RIBBI group.
So you are probably getting a fake bold.
You can tell because the fake Bold is probably wider than the Regular (or Light in your case), and being monospace it should be the same width as the regular/Light.
Take a look and see if you have that happening.

The same thing happened with another font family, but with Notepad++.
The user wanted to use Light and Medium.
Just style-linking those (as Regular and Bold) did not work.
I had to actually change the Light to Regular, and the Medium to Bold, and the same for the Italics, and made a new RIBBI four font set.
That worked in Notepad++.
We may have to do the same thing here.

So be aware and note if you see fake bold or fake italic.