Closed adiabatic closed 1 month ago
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:
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}
.
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
Regular
, Italic
, Bold
, and BoldItalic
)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
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)
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.
Investigating!
Working on a fix for this, will update shortly! Thanks for spotting the metadata issue @Finii @kenmcd 🙏
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:
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 :grimacing:
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?
Should be fixed in e6f6278955d3c47a77c1bdbf442f60838667cb98! Thank you for the report 🥰
@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.
@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).
Thank you for these details. Is there an issue I could subscribe to?
@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?
It displays v1.101.
@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.
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.
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.
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.