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

MonaspiceNe Nerd Font Mono ss06 causing characters to overlay on each other #1503

Closed
3 tasks done
TehPers opened this issue Feb 1, 2024 · 16 comments · Fixed by #1630
Closed
3 tasks done

MonaspiceNe Nerd Font Mono ss06 causing characters to overlay on each other #1503

TehPers opened this issue Feb 1, 2024 · 16 comments · Fixed by #1630

Comments

@TehPers
Copy link

TehPers commented Feb 1, 2024

🗹 Requirements

  • I have searched the issues for my issue and found nothing related and/or helpful
  • I have searched the FAQ for help
  • I have searched the Wiki for help

🎯 Subject of the issue

Experienced behavior:

When enabling ss06 on MonaspiceNe Nerd Font Mono, characters after consecutive #s end up overlayed with the #s:

image

I was able to confirm that MonaspiceNe Nerd Font and MonaspiceNe Nerd Font Propo have the correct behavior.

Screenshot is from vscode, but I was able to reproduce the issue in Windows Terminal as well:

image

Expected behavior:

The same behavior as Monaspace Neon/MonaspiceNe Nerd Font/MonaspiceNe Nerd Font Propo:

image

For comparison, with ss06 disabled:

image

Example symbols:

The main symbol I've noticed affected is #. I haven't noticed any others, but as far as I know, ss06 only affects #.

###$$$$

🔧 Your Setup

  • Which font are you using (e.g. Anonymice Powerline Nerd Font Complete.ttf)?
    • MonaspiceNeNerdFontMono-*.otf - as far as I can tell, affects all variants of it. Confirmed with Light and Regular at least
  • Where did you get the file from (download link, self patched, source downloaded from link...)
    • Releases page (v3.1.1) - Monaspace.zip, also tested Monaspace.tar.xz
  • Which terminal emulator are you using (e.g. iterm2, urxvt, gnome, konsole)?
    • Windows Terminal, behavior also observed in vscode
  • Are you using OS X, Linux or Windows? And which specific version or distribution?
    • Windows 11 Pro 22H2

★ Screenshots (Optional)

image

image

settings.json for Windows Terminal:

image

Copyable settings:

{
    "font": {
        "face": "MonaspiceNe Nerd Font Mono",
        "features": {
            "calt": 1,
            "liga": 1,
            "ss03": 1,
            "ss06": 1,
            "ss08": 1
        }
    }
}
@Finii
Copy link
Collaborator

Finii commented Feb 1, 2024

Thanks for reporting with very good details!
And sorry to hear of your problem.

I believe I instantly know from your description what the problem is:
Unlike all (?) other fonts that have programming ligatures Monaspace uses a different and problematic approach to implement these. I already commented on that fact upstream [1].

The problem I see is that they would need to invest a considerable amount of time to 'fix' the ligatures; it is unclear for me if they will ever get the time for that. The ligs work, somehow, with some limitations, so why spend time and money ...

Let me think a bit about the issue and if there is any generic way we can avoid the problem.
Feel free (you are welcome to) ping me again if I forget to answer within a week or so.

P.S. Do you not see [1a] in VScode? With the non-NerdFontMono patched versions or the unpatched one?

[1a] https://www.github.com/githubnext/monaspace/issues/115
[1b] https://www.github.com/githubnext/monaspace/issues/132

Links without backlink as this Issue is not really helpful over there

@TehPers
Copy link
Author

TehPers commented Feb 1, 2024

For 1a, I notice the same behavior that's in that issue when using the non-NFM patched version, so that's definitely an issue with Monaspace. I do notice that the behavior is a bit different with the NFM variant though. To fully explain the issue (though this is not a NFM issue, but there are differences between the two variants):

With non-NFM (normal Monaspace Neon), while the cursor appears after the arrow, in reality the cursor is between the = and > characters, just not visually:

image

When pressing the right arrow key, you actually need to press it twice to pass through the =>, one to go past the = and the other to go past the >, though the cursor visually stays at the end of the line here.

With the NFM patched version (MonaspiceNe Nerd Font Mono), while the behavior is almost entirely the same, the difference is that the cursor is now stuck in the middle of the two characters:

image

As for the behavior noted in this issue, I've only noticed that behavior with the NFM variants of the fonts.

If this issue can't be solved from the Nerd Font side, feel free to close the issue. This does seem like an issue with Monaspace itself at the very least.

Also, just tested with MonaspiceNe Nerd Font (non-Mono) and it has the same behavior as Monaspace (non-NF)

@TehPers
Copy link
Author

TehPers commented Feb 2, 2024

Adding more context, looks like this happens with other ligatures as well. For example, from ss03, the ligature for <!-- seems to have a similar issue.

Here's from MonaspiceNe Nerd Font (Monaspace Neon looks the same as this):

image

Here's from MonaspiceNe Nerd Font Mono:

image

@Finii
Copy link
Collaborator

Finii commented Apr 9, 2024

Well, that all is the problem because Monaspace's idea of how to create the ligs.
I wonder how much work it really is and if I should just change the ligs in Glyph3 and upload a PR at the Monaspace repo.
But then, the repo seems ... not watched by anyone at the moment. Maybe we should try to reach someone and clarify the state.
I guess the Ligs could be fixed within some few days 🤔

But then, why should I invest time there, I can not fix all and everything. I already now have no time left.

@TehPers
Copy link
Author

TehPers commented Apr 9, 2024

To be clear - I'm not saying that it needs to be fixed here. Just wanted to report it as an issue, feel free to close as "wont fix" if you feel like it falls into Monaspace's domain to fix.

@Finii
Copy link
Collaborator

Finii commented Apr 10, 2024

It does indeed.
Well, in some exceptional circumstances we fix bug in sourcefonts locally here, like for example

(which is still not fixed upstream despite the pending PR that they even said they will merge).

I mark this as wontfix as you suggested but keep it open to not forget it. Maybe I have to attend some boring meeting and can work on it then 😬

@Finii
Copy link
Collaborator

Finii commented Apr 10, 2024

@allcontributors please add @TehPers for bug

Copy link
Contributor

@Finii

I've put up a pull request to add @TehPers! 🎉

@mihaicris-adoreme
Copy link

I have a similar issue with Iosekva font

installed with macoS brew:
font-iosevka
font-iosevka-nerd-font

Top: Yosevka Fixed
Bottom: Yosevka Nerd Font Mono

image

Where should I address this problem?

Thank you

@Stealthii Stealthii mentioned this issue May 7, 2024
4 tasks
@Stealthii
Copy link
Contributor

@TehPers would you be able to verify if the v1.100 fonts implemented in #1630 resolve all issues you are experiencing?

@TehPers
Copy link
Author

TehPers commented May 9, 2024

@TehPers would you be able to verify if the v1.100 fonts implemented in #1630 resolve all issues you are experiencing?

@Stealthii It's my first time running the font patcher myself, so I'll include the command I ran when checking out the PR branch:

docker run --rm -v /path/to/nerd-fonts/src/unpatched-fonts/Monaspace:/in:Z -v /path/to/nerd-fonts/patched-fonts/Monaspace:/out:Z nerdfonts/patcher --mono --complete

After uninstalling the old font, running the above command, and reinstalling MonaspiceNe Nerd Font Mono (all of the generated MonaspiceNeNerdFontMono-*.otf files), the ss06 ligatures seems to be working as expected. Thanks!

image

@TehPers
Copy link
Author

TehPers commented May 10, 2024

See second edit, but this doesn't appear to be a NF-related problem.

@Stealthii I've been using the updated font (MonaspiceNe Nerd Font Mono, generated from your PR), and I found an interesting related issue with a different stylistic set. I know that your PR is only addressing updating Monaspace to v1.100, but just including it here since it seems to be related. This may also be an issue with vscode. To be honest, I'm not entirely sure how to debug where this issue comes from, so I'll include screenshots here, and I can open up an issue on the appropriate repository if anyone has suggestions.

Using ss07, if there are three colons next to each other and there is red squigglies under what comes immediately after the colons, the cursor steps through the three characters as though the first two are 1.5 wide and the third is 0 wide. This is with the cursor logically between the first and second colon (from the left):

image

This is without red squigglies:

image

It's a bit hard to try to reproduce this with ss06's ligatures, but here's an attempt (which does not exhibit the same problem):

image

I'm not really sure why this only happens when there are red squigglies. I couldn't reproduce it with yellow squigglies:

image

(If you're trying to reproduce, the first images used Rust, third image was Rust but on the first line as a messed up shebang, and the last one was Markdown)

Edit: Here's with the ss07 ligatures disabled. Looks like one of the inner colons gets squigglies in the Rust code, which might be what's causing it? This might just be a limitation of vscode if that's the case, but I'm just guessing here.

image

Edit 2: I started investigating this further, and this is with Monaspace Neon v1.100 and v1.101 respectively (same issue):

image

image

v1.000 doesn't seem to have the ligature, which is likely why I wasn't seeing this before:

image

For fun, I also tried Fira Code with ligatures enabled (since it has a ligature for :::), and it seems to not have this issue:

image

This seems to me to be an issue with Monaspace itself and not with NF, and my guess is it isn't a vscode issue either since Fira Code seems to be working fine. Maybe I'll open an issue on Monaspace about this.

@tukykarmakar
Copy link

When using ShureTech Mono font in Konsole, typing anything with 'fl' or 'fi' causes the letter after i or l to overlap on them. For example, the 'l' and 'a' for flatpak overlap, and the 'i' and 'g' for config overlap. The screenshot below shows some more examples.
Konsole-fonts-bad-spacing_02

I tried using other Nerd Fonts, but it seems like this is happening for ShureTech Mono only. ShureTech Regular and Propo are also having issues with bold letters.

@Finii
Copy link
Collaborator

Finii commented May 12, 2024

When using ShureTech Mono font in Konsole, typing anything with 'fl' or 'fi' causes the letter after i or l to overlap on them.

Duplicate of #1631, fixed.
There is also a fixed font pack in that Issue that you can download.

ShureTech Regular and Propo are also having issues with bold letters.

What does that mean? Probably like #1515? "Bold" letters come in from another font, and there is most likely nothing Nerd Fonts can do. Hmm, well, at least if that is what you mean, report in 1515, so I have all comments in one Issue.

Edit: Add mention of fixed ShareTech font set for download
Edit: Ah you already reported in 1515! 👍

@MicaelJarniac
Copy link
Contributor

Possibly related: githubnext/monaspace#190

@TehPers
Copy link
Author

TehPers commented Jul 1, 2024

I should probably mention this, but the original issue I posted seems to be resolved by #1630 as far as I can tell. MonaspiceNe no longer has the overlapping characters.

I opened an issue on Monaspace for the other issue I came across. That does not seem to be a NF issue since it seems to happen with base Monaspace as well.

If we want to continue to use this issue thread for other instances of overlapping characters, then feel free, but I just wanted to make it clear that my issue is resolved by that PR at least.

@Finii Finii closed this as completed Oct 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants