Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow specifying MonoLisa font weight #246

Open
xshapira opened this issue Dec 6, 2023 · 21 comments
Open

Allow specifying MonoLisa font weight #246

xshapira opened this issue Dec 6, 2023 · 21 comments
Labels
bug Something isn't working

Comments

@xshapira
Copy link

xshapira commented Dec 6, 2023

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.

@xshapira xshapira added the bug Something isn't working label Dec 6, 2023
@bebraw
Copy link
Contributor

bebraw commented Dec 6, 2023

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.

@sonulohani
Copy link

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?

@bebraw
Copy link
Contributor

bebraw commented Dec 15, 2023

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.

@sonulohani
Copy link

sonulohani commented Dec 16, 2023

@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.

@bebraw
Copy link
Contributor

bebraw commented Jan 19, 2024

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.

@xshapira
Copy link
Author

@bebraw How do you achieve 450 weight with the Complete version in VS Code?

@bebraw
Copy link
Contributor

bebraw commented Jan 19, 2024

@xshapira I have VS Code instructions here.

@xshapira
Copy link
Author

@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": ""
        }
      }
    ]
  },

@bebraw
Copy link
Contributor

bebraw commented Jan 19, 2024

@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.

@bebraw
Copy link
Contributor

bebraw commented Jan 19, 2024

@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.

@xshapira
Copy link
Author

@bebraw I think implementing weight mapping for Complete would be a much better option than a cumbersome workaround.

@bebraw
Copy link
Contributor

bebraw commented Jan 19, 2024

@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.

@mfocko
Copy link

mfocko commented Feb 15, 2024

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 Cascadia1?)

Footnotes

  1. IIRC they just have more granular weights…

@bebraw
Copy link
Contributor

bebraw commented Feb 15, 2024

@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
Copy link

mfocko commented Feb 15, 2024

@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?

@bebraw
Copy link
Contributor

bebraw commented Feb 15, 2024

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).

@mfocko
Copy link

mfocko commented Feb 15, 2024

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.

@bebraw
Copy link
Contributor

bebraw commented Feb 15, 2024

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.

@mfocko
Copy link

mfocko commented Feb 15, 2024

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 :)

@mfocko
Copy link

mfocko commented Jul 16, 2024

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 :/

@gennaios
Copy link

gennaios commented Nov 25, 2024

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants