Open xshapira opened 12 months ago
Reference: https://github.com/jonpalmisc/vfit . There's the needed fonttools
code that instantiates variants with arbitrary weights.
I guess there's some kind of a UI problem to solve depending on how far to go.
Reference: https://github.com/jonpalmisc/vfit . There's the needed
fonttools
code that instantiates variants with arbitrary weights.I guess there's some kind of a UI problem to solve depending on how far to go.
But this needed variable fonts, Is variable font available for Plus users?
But this needed variable fonts, Is variable font available for Plus users?
No, but since we derived the static versions from a variable one, the fix might be applicable to this use case.
As mentioned, I wonder what the remapping UI should look like. I guess you should be able to tell the UI to "nudge" weights to a direction or another somehow within the available range within Plus.
@bebraw I am also holding plus license, Could it be possible for you to provide medium weight as 450 instead of 500, 500 is too bold for me.
We had a brief discussion about this. There were two outcomes 1. For more customization (i.e., 450 weight), it's best to go with the Complete version as it was designed for the purpose. 2. We'll consider adding a more specific customization UI for Complete to allow mapping of static weights as it's a good feature for the plan.
@bebraw How do you achieve 450 weight with the Complete version in VS Code?
@bebraw Thanks! I upgraded from Plus to Complete, but now the bold text styling isn't working (for specific scopes). Am I doing something wrong?
Here's my settings.json
:
"editor.fontFamily": "MonoLisa Variable, FiraCode-Retina, Fira Code Retina, Fira Code, Consolas Ligaturized, Menlo, Monaco, 'Courier New', monospace",
"editor.fontWeight": "450",
"editor.fontVariations": true,
"editor.tokenColorCustomizations": {
"textMateRules": [
{
"name": "italics & bold",
"scope": [
//following will be in italic bold
"keyword", //import, export, return…
"keyword.control.flow",
"storage.modifier", //static keyword
"storage.type"
],
"settings": {
"fontStyle": "italic bold"
}
},
{
"name": "No italics",
"scope": ["comment", "keyword.operator", "keyword.key"],
"settings": {
"fontStyle": ""
}
}
]
},
@xshapira I have a feeling the problem might be that settings.fontStyle
portion. I wonder if it's possible to point to specific font weights by number at textMateRules
. There might be some restrictions in place and I imagine VS Code support has better idea on that. In case this isn't possible at VS Code side, it would be one more reason to implement weight mapping for Complete to work around the limitatoin.
@xshapira The closest potential solution I could find is this: https://gist.github.com/psgganesh/d0815ece4b19ce24dde98e21d55f53f5 . There they set up custom CSS where they push the problem.
@bebraw I think implementing weight mapping for Complete would be a much better option than a cumbersome workaround.
@xshapira Yup. I can see two directions - 1. we'll add weight mapping 2. VS Code setup gets improved for textmateRules
. For latter, I would recommend opening a related issue unless there's one to bring the problem to their attention. They may be able to suggest a better workaround than going through a plugin to add custom CSS.
Hi, I've noticed this issue some time ago. I got Complete version recently and I used to use weight 350
for Cascadia Code for dark themes as it was looking the best to me. Cascadia and MonoLisa share pretty similar weight IMO, so I thought the 350
might look pretty good, but with the variable version it appears that I'm getting 300
with 350
defined no matter what I do (the weight doesn't change between 350
and 300
).
Does the variable font mean that it's just one file with all the weights? (as opposed to Fira Code or Cascadia[^1]?)
[^1]: IIRC they just have more granular weights…
@mfocko The variable version needs special support from an editor. So far VS Code implements it the best and the setup has been covered here. In case of the variable font, it's effectively shipping all the weights in two files (normal and italic) since it contains all the necessary information. Note that there's a variable version of Fira Code available as well in case you want to compare/debug.
@mfocko The variable version needs special support from an editor. So far VS Code implements it the best and the setup has been covered here. In case of the variable font, it's effectively shipping all the weights in two files (normal and italic) since it contains all the necessary information. Note that there's a variable version of Fira Code available as well in case you want to compare/debug.
The issue I'm having is that when I set fontVariations: true
, the fontWeight
has no effect (Fedora 39, Plasma, VSCode Insiders), otherwise it works fine.
Anyways, in the link you provided I see:
400 is regular and the rest are with 100 increments (300 for light for example and 700 for bold).
Which means that there is no 350, right? Only the ones listed on the website in the FAQ?
The issue I'm having is that when I set fontVariations: true, the fontWeight has no effect (Fedora 39, Plasma, VSCode Insiders), otherwise it works fine.
Something seems off. When I have only the variable version installed, it's picking up arbitrary weights from the range as expected.
I would try installing only the variable version to rule out any lookup related issue since the static version has the same name.
You can also try how it behaves with another variable font like Fira Code to see if you see the same issue.
Which means that there is no 350, right? Only the ones listed on the website in the FAQ?
For the static build, only increments of 100 are supported. The variable version supports all weights from the overall range (from 100 to 800 I think).
fontVariatons: true
breaks the weights for all fonts (tried with MonoLisa and Cascadia). This might be a change in the behavior, I'm just using what works for me :)
the only difference I can see is:
mfocko@ampere ~
λ fc-list | grep CascadiaCodePL\.ttf
…/CascadiaCodePL.ttf: Cascadia Code PL:style=Regular
…/CascadiaCodePL.ttf: Cascadia Code PL
…/CascadiaCodePL.ttf: Cascadia Code PL:style=SemiBold
…/CascadiaCodePL.ttf: Cascadia Code PL:style=Bold
…/CascadiaCodePL.ttf: Cascadia Code PL:style=SemiLight
…/CascadiaCodePL.ttf: Cascadia Code PL:style=Light
…/CascadiaCodePL.ttf: Cascadia Code PL:style=ExtraLight
mfocko@ampere ~
λ fc-list | grep MonoLisaVariableNormal\.ttf
…/MonoLisaVariableNormal.ttf: MonoLisa Variable:style=ExtraBold
…/MonoLisaVariableNormal.ttf: MonoLisa Variable:style=SemiBold
…/MonoLisaVariableNormal.ttf: MonoLisa Variable
…/MonoLisaVariableNormal.ttf: MonoLisa Variable:style=Black
…/MonoLisaVariableNormal.ttf: MonoLisa Variable:style=ExtraLight
…/MonoLisaVariableNormal.ttf: MonoLisa Variable:style=Thin
…/MonoLisaVariableNormal.ttf: MonoLisa Variable:style=Bold
…/MonoLisaVariableNormal.ttf: MonoLisa Variable:style=Regular
…/MonoLisaVariableNormal.ttf: MonoLisa Variable:style=Medium
…/MonoLisaVariableNormal.ttf: MonoLisa Variable:style=Light
The SemiLight
by Cascadia should be 350, so I guess that it only takes what is “detected”; might be Linux-only issue, I don't have other OS to test it on.
The SemiLight by Cascadia should be 350, so I guess that it only takes what is “detected”; might be Linux-only issue, I don't have other OS to test it on.
Yeah, it might be something OS related. I was testing on MacOS myself.
Each variable font comes with definitions for the static weights as well so that name based lookups work. That's what you are seeing in the output. Technically it's mapping a name to a specific number within the typeface if I understood correctly and allows OS to show different static weights by name.
I'll look into it further, so far I didn't need to do any tinkering because of the fonts :D thanks a lot for the debugging session :)
Confirming it's Linux-specific issue. Tested with HTTP server serving both page with different weights and MonoLisa from local installation and HTTP server (loaded via CSS); local doesn't produce all the desired weights, whereas the font loaded via CSS does…
Haven't managed to find any documentation on how to fix that locally :/
Related to such, I find regular weight not quite as readable at smaller sizes compared to some fonts said to be designed for Retina screens. From what I recall Dank Mono or some other font was quite readable yet it doesn’t have as as wide a range of unicode characters as MonoLisa. Fira Code has a retina weight yet I haven’t tried it.
I’m not sure if such fonts just use a different weight for Retina or if they do something else. I currently use Light in my text editor though a different weight might be better. Would you consider adding such to Plus?
Edition
Plus
What version are you using?
2.010
What type of weights are you using?
Default (non-customized)
Operating system
MacOS Monterey 12.7
Program
VS Code, Zed, SnippetsLab
Display resolution
No response
What happened?
In some editors/apps, I cannot access the MonoLisa Medium variant (500 font weight). The reason is unlike VS Code, they don't let you change the font's weight.
It would be great if I could specifically access the, e.g., MonoLisa-Medium rather than being stuck with whichever weight the MonoLisa family defaults to. Could the MonoLisa family be ungrouped? That would let us select just the weight that we prefer.