MonoLisaFont / feedback

Send us your feedback regarding the MonoLisa font
86 stars 2 forks source link

Allow specifying MonoLisa font weight #246

Open xshapira opened 10 months ago

xshapira commented 10 months ago

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.

bebraw commented 10 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.

sonulohani commented 9 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.

But this needed variable fonts, Is variable font available for Plus users?

bebraw commented 9 months ago

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 commented 9 months ago

@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 commented 8 months ago

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 commented 8 months ago

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

bebraw commented 8 months ago

@xshapira I have VS Code instructions here.

xshapira commented 8 months ago

@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 commented 8 months ago

@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 commented 8 months ago

@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 commented 8 months ago

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

bebraw commented 8 months ago

@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 commented 7 months ago

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…

bebraw commented 7 months ago

@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 commented 7 months ago

@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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 2 months ago

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