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

Font renders brighter and slightly thicker #1231

Closed
gmr458 opened this issue Feb 26, 2022 · 33 comments
Closed

Font renders brighter and slightly thicker #1231

gmr458 opened this issue Feb 26, 2022 · 33 comments
Labels
bug Something isn't working

Comments

@gmr458
Copy link
Contributor

gmr458 commented Feb 26, 2022

Describe the bug
Neovide makes fonts look bold when they are actually regular or light.

To Reproduce
Steps to reproduce the behavior:
Use a regular or light font in a terminal emulator and Neovide and see the difference.

Expected behavior
That the font I use looks the same weight as it does in the terminal emulator.

Screenshots
Terminal emulator:
alacritty

Neovide:
neovide

Desktop (please complete the following information):

  • OS: Ubuntu 20.04.4 LTS
  • Neovide Version 0.8.0
  • Neovim Version 0.6.1

Please run neovide --log and paste the contents of the .log file here:
https://0bin.net/paste/9jSydr9u#-wgXMfCZAPBxXYI7XC6EZ7I1GFYbS2mXW4HFb+Em1RY

@gmr458 gmr458 added the bug Something isn't working label Feb 26, 2022
@zoomlogo
Copy link
Contributor

zoomlogo commented Mar 3, 2022

To me the font looks brighter in neovide (it doesn't look like the weight of the font has changed). This is probably due to the way neovide handles fonts.

@kabouzeid
Copy link

The font is definitely more bold too. I'm also experiencing this issue.

@Kethku
Copy link
Member

Kethku commented Mar 6, 2022

Its possible this is a font selection issue on linux. Though, like @PyGamer0, I'm not convinced this isn't just a subtle change in the way the font is rendered. As such I'm going to change the name of this issue unless someone can show a side by side comparison which shows the bold variant of a font which matches the font rendered in neovide.

@Kethku Kethku changed the title Noevide force bold in the font Font renders brighter and slightly thicker in neovide Mar 6, 2022
@Kethku Kethku changed the title Font renders brighter and slightly thicker in neovide Font renders brighter and slightly thicker Mar 6, 2022
@kabouzeid
Copy link

The font is only rendered more bold, it's not actually a different font. For example my icon font is rendered considerably more bold and it certainly doesn't have a bold font variant.

@phdpe
Copy link

phdpe commented Mar 11, 2022

The font is only rendered more bold, it's not actually a different font. For example my icon font is rendered considerably more bold and it certainly doesn't have a bold font variant.

Yes, I just installed Neovide on Windows and noticed the difference too. I tried to set guifont with w or l but neither works...

@rmccord7
Copy link

I just installed neovide on windows as well and I see the same thing.

@gmr458
Copy link
Contributor Author

gmr458 commented Feb 4, 2023

For some reason Neovide renders fonts in a way that makes them look thicker than they are, here's a comparison:
*open each image in different tabs to clearly see the difference

Alacritty:
alacritty

Neovide:
neovide

@gmr458
Copy link
Contributor Author

gmr458 commented Feb 4, 2023

I tried all the available edging and hinting combinations and none of them achieves a result similar to Alacritty or Kitty.

@gmr458
Copy link
Contributor Author

gmr458 commented Feb 4, 2023

font renders correctly when using light theme as someone says in this issue #1635

@avegancafe
Copy link

This is also happening to me. Seems like a very common bug, I've seen quite a few threads that seem to say they've resolved them and even with the proposed fixes it still isn't the same.

@oredaze
Copy link

oredaze commented Feb 13, 2023

I have been trying for some time (again) to get neovide to render fonts properly, but to no avail.
You can see that it's bolder and even wider/stretched vs terminal neovim.
2023-02-13-184752_1440x900_scrot
terminal uses size of 12, but I have to put 11.3 to get close on neovide. The other options don't do much. (I have been through all of them)

@gmr458
Copy link
Contributor Author

gmr458 commented Sep 21, 2023

@avegancafe Could you give me links to those threads please?

@fredizzimo
Copy link
Member

@oredaze

That issue is slightly different than the one reported here, although you do see too thick glyphs as well

But your main issue is that the font size is rendered wrong.

An IBM Plex Mono font with a size of 12 has the pixel dimensions of 16.0 x 9.6. Neoivde uses an integer sized grid, so something has to be done to render the font properly. There are a few different approaches:

  1. Automatically resize the font so that the width is an integer. Neovide takes this approach by default if you specify the font size as an integer. So, the actual font size becomes 12.48 with a pixel size of 16.67 x 10.0 pixels. With this approach the line spacing becomes slightly wrong, since that can't be fractions either. But since that is typically less critical, this is the default.
  2. Don't resize the font, and adjust the letter spacing instead. This is what happens when you specify a font size as a fraction, for example 12.0. In that case the rendered font size is still 16.0 x 9.6, but the letter spacing will be 10 pixels, so it renders too wide.
  3. Use a fractional sized grid and render with supixel positioning. This way the font size and all spacings will be correct. But it requires support for positioning the glyphs using subpixels. I'm pretty sure that the Skia libary we use do support that, so we should probably add support for it at some point. The fonts might appear slightly blurrier this way, since now neither the width nor height matches exact pixels anymore. But it looks like this is the approach your "terminal" (you didn't specify which) takes.

@fredizzimo
Copy link
Member

fredizzimo commented Sep 21, 2023

As for the original problem that can be fixed by

diff --git a/src/renderer/fonts/font_loader.rs b/src/renderer/fonts/font_loader.rs
index 0a36a9a8..0d9328e2 100644
--- a/src/renderer/fonts/font_loader.rs
+++ b/src/renderer/fonts/font_loader.rs
@@ -3,8 +3,9 @@ use std::sync::Arc;
 use log::trace;
 use lru::LruCache;
 use skia_safe::{
-    font::Edging as SkiaEdging, Data, Font, FontHinting as SkiaHinting, FontMgr, FontStyle,
-    Typeface,
+    font::Edging as SkiaEdging,
+    font_style::{Slant, Weight, Width},
+    Data, Font, FontHinting as SkiaHinting, FontMgr, FontStyle, Typeface,
 };
 
 use crate::renderer::fonts::font_options::{FontEdging, FontHinting};
@@ -163,7 +164,7 @@ fn font_style(bold: bool, italic: bool) -> FontStyle {
         (true, true) => FontStyle::bold_italic(),
         (false, true) => FontStyle::italic(),
         (true, false) => FontStyle::bold(),
-        (false, false) => FontStyle::normal(),
+        (false, false) => FontStyle::new(Weight::LIGHT, Width::NORMAL, Slant::Upright),
     }
 }

I don't know why Skia renders weight normal (400) thicker than it should. Or maybe the CSS font weights means something different than regular UI font weights? But that's something we need to figure out, changing the weight to light does not sound like the correct fix.

Also note that we should make both weight and width configurable, once we have figured out the proper configuration format for the fonts.

@fredizzimo
Copy link
Member

fredizzimo commented Sep 21, 2023

Actually, after more investigation I'm not convinced that we render the thickness wrong.

I compared the size rendered by chrome Windows (note that the colors are not quite matching, because chrome renders sRGB colors)

image

image

So, if we are rendering it wrong, then Chrome is doing it too. But depending on the background and font color some fons might appear slightly bolder.

Finally, I'm not sure if we should consider Alacrity the gold standard of font rendering. But here's the same comparision
image

Its font weight looks closer to Chrome's light.

And finally, Neovide against Notepad
image

@fredizzimo
Copy link
Member

It would be great if someone could do a similar comparison on other platforms as well. For the web browser images I used https://fonts.google.com/, and edited the website style with the fonts and backgrounds.

Since the font sizes are not exact as explained in #1231 (comment), I also adjusted them slightly for roughly matching sizes.

But at least based on the above images, I would close the issue and say that Alacritty renders it wrong. Note that Noevide renders this too wide, because I use floating point sizes here to make the actual glyph size the same

One more comparison, Chrome, Neovide, WezTerm, Alacrity, Windows Terminal, and Notepad. Alacritty stands out the most, it also renders the font width completely wrong. Note that Neovide also renders the width wrong, because I use floating point sizes to match the size of the others.
image

@gmr458
Copy link
Contributor Author

gmr458 commented Sep 25, 2023

@fredizzimo Did you see my second post in this thread? You can see the difference easier if you zoom in on the screenshots, I'm going to do the same, but with other terminals. I also want to point out that this happens when the background is dark and the font is light.

Something I want to say that might be helpful:
While I was installing other terminals to make the comparison, I arrived at Kitty, it had been a while since I had used it and when I configured it with the same font and font size as the other terminals I noticed that it looked thicker than I remembered, it seems that Kitty has a new option called text_composition_strategy, it has two options, platform and legacy, the legacy option makes the font in Kitty look like I remembered it and according to the documentation "A value of legacy uses the old (pre kitty 0.28) strategy for how glyphs are composited. This will make dark text on light backgrounds look thicker and light text on dark backgrounds thinner.", this caught my attention, is it possible that Neovide is doing something similar and that is why the font looks thicker?

More information about Kitty's option text_composition_strategy

Here comes the comparison, to appreciate the difference I recommend opening each image in a tab of your browser on your laptop or desktop PC and switch between tabs.

Alacritty:
alacritty

Foot:
foot

Kitty (text_composition_strategy = legacy):
kitty_legacy

WezTerm:
wezterm

Kitty (text_composition_strategy = platform):
kitty_platform

Neovide:
neovide

Alacritty, Foot and Kitty with the legacy option look almost the same, Wezterm looks different, Kitty with the platform option makes the font look thicker, I prefer how it looks with the legacy option, Neovide looks thicker than Alacritty, Foot and Kitty with The legacy option, you can see how it has extra pixels around the characters, Kitty with the platform option although it looks thicker, does not do this.

It's possible that there is a "legacy" option in Neovide like there is in Kitty?

@fredizzimo
Copy link
Member

Do you have the images in their original sizes? It's impossible to do a proper comparison with zoomed in images like that. That's not how you look at the fonts in real life.

But other than comparing different, programs to each other there's very little we can do. We use the same font rendering engine as all Chromium based browsers, so unless you can prove that we do something wrong and those browsers render the text differently, I think this bug will stay as a won't fix.

The only thing we can do is to allow a configurable weight, which can be numeric typically between 0 and 1000 and 400 as the default. By modifying the code, you can already test it out as I explained here #1231 (comment).

It's also very subjective. at least on Windows I find the Neovide and Edge font rendering to be the most readable. But other people probably have different opinions.

@gmr458
Copy link
Contributor Author

gmr458 commented Sep 25, 2023

It's impossible to do a proper comparison with zoomed in images like that. That's not how you look at the fonts in real life.

You are right, I just thought this was the best way to see the difference, those little pixels make the difference.

you can already test it out as I explained here #1231 (comment)

I will try

Here are the images in their original size:

Alacritty:
alacritty_full

Foot:
foot_full

Kitty (text_composition_strategy = legacy):
kitty_full_legacy

Kitty (text_composition_strategy = platform):
kitty_full_platform

WezTerm:
wezterm_full

Neovide:
neovide_full

@fredizzimo
Copy link
Member

fredizzimo commented Sep 25, 2023

To me there doesn't seem to be a huge difference, other than for the really bright colors. But admittedly that inconsistency looks pretty bad. I have not noticed that on Linux myself since my color scheme (everforest) does not suffer from that.

Which color scheme and font is that, so I can replicate it exactly? I'm guessing vim-code-dark, which looks like this on Windows for me. I don't have LSP and treesitter enabled in this test config so some of the highlights are missing. But generally, it looks like the rendering is much more consistent on Windows. I will try on Linux at some point, are you on X11 or Wayland?

Edit: It's not the same theme, your background is completely black, mine is not. I will try again when I know what it is.

image

@gmr458
Copy link
Contributor Author

gmr458 commented Sep 25, 2023

Which color scheme and font is that, so I can replicate it exactly?

The font is Roboto Mono, font size 10.5, color scheme is dark_modern.nvim with transparent background and the background of my terminal is black.

are you on X11 or Wayland?

Wayland

@fredizzimo
Copy link
Member

Strange The color scheme does not seem to match, it should be dark_modern as printed at the bottom. The vim_code_dark, looked much closer. Anyway, on windows the font width looks consistent for all colors. But the dark mode sharpness suffers a bit from the transparency, compared to the regular background.

image

And there are not much difference between dark and white backgrounds (both transparent)

image

@fredizzimo
Copy link
Member

fredizzimo commented Sep 25, 2023

I switched to my regular configuration with lua LSP.

And no overly bright colors or mismatching widths. So, I guess this is mostly a Linux specific problem. The font might be slightly thicker than some of your examples, but compared to other Windows terminals and programs it seems to be comparable at least.
image

Edit: Overall the colors are brigther, but at the same time closer to what they should be if the font was big enough to be several pixels wide. It's also very close to Kitty with the platform rendering, but not quite as thick and bright.

@gmr458
Copy link
Contributor Author

gmr458 commented Sep 25, 2023

I did the comparison on Windows and the font in Neovide looks thicker than Alacritty:

Here I am using the builtin colorscheme industry (execute :colorscheme industry), this colorscheme shows keywords and the current line number in bold, so I used these commands to make sure there were no bold characters in the screenshot.

hi CursorLineNr cterm=NONE gui=NONE
hi Statement cterm=NONE gui=NONE
hi Type cterm=NONE gui=NONE

Alacritty:
alacritty_final

Neovide:
neovide_final_final

@fredizzimo
Copy link
Member

fredizzimo commented Jan 13, 2024

I believe this added as much customization as we can allow through skia

Note that the color is mostly a function of the weight for small font sizes, thinner fonts on dark backgrounds will get darker, and lighter on light backgrounds. All terminals and Neovide renders the fonts too dark on dark backgrounds, so none of it is correct, and therefore the correctness is subjective.

The correct weight is also subjective, since it's not possible to render correctly unless you have a very high dpi display.

To fully compare the colors you should use a big font that with lines that are several pixels wide.

I'm closing this, but will open when someone can give a clear non-subjective reason why we are rendering wrong.

NOTE: some macOS systems render the colors wrong compared to terminals due to lack of srgb support

@tghosgor
Copy link

tghosgor commented Apr 14, 2024

I have this issue as well. I have used neovim-qt before but I wanted to get rid of qt5 so I have been using neovim on foot terminal for a while now. I have tried out neovide but while neovim-qt & foot exactly match the font rendering, neovide does some weird thing where fonts are thicker and fuzzier. Extents of certain letters are shorter and icons are smaller. No hinting/aliasing option remedied the issue. I use the plain DejaVu Sans Mono. Unfortunately, I see that the sole maintainer is reluctant to acknowledge the many issues that have been created about font rendering so I am not going to bother creating a new one.

@fredizzimo
Copy link
Member

fredizzimo commented Apr 28, 2024

A recent Skia update now made this configurable, so here you go:

As you can see in the screenshots there, everything is a compromise, different terminal emulators render things differently and so does Neovide. But even before that change, Neovide had more accurate colors and worked better on all backgrounds than most.

strayer added a commit to strayer/dotfiles-nvim that referenced this issue Apr 29, 2024
@tghosgor
Copy link

tghosgor commented Apr 29, 2024

Now that I've investigated specific cases more, I'll agree. But I am bummed because overall the things are better but the font fuzziness becomes a real problem when the font is set to a small value. I can barely differentiate between { and ( in neovide (because of the boldness and the { is somehow shorter) whilst it is different enough in foot. ; is even worse.

Foot:
image
image

Neovide:
image
image

Neovide aliased:
image
image

#e-alias can make things even better in certain cases (i.e. above) but then it is too aliased overall. I think the issue I and probably other people are complaining about might be the antialiasing. Maybe the way antialiasing happens in neovide somehow makes things bolder/rounder? It feels like neovide's antialiasing goes quite far when compared to foot.

Anyway, I wish I knew how the font stuff worked so I could prepare a solution proposal for this but I have no idea.

@gmr458
Copy link
Contributor Author

gmr458 commented Apr 29, 2024

@tghosgor Please read the comment before yours, there is a PR opened by the creator of Neovide that adds a couple of configurations that can help you solve your problem, I actually cloned the branch of the PR and was able to emulate the font rendering from Alacritty.

@fredizzimo
Copy link
Member

fredizzimo commented Apr 29, 2024

@tghosgor, I wonder if you have your monitor setup wrong, because all of your screenshots are very clear to me, with Neovide being the clearest.

But in any case, I think you should get it close to foot and alacritty by setting neovide_gamma=0.8 and neovide_contrast=0.2.

For the deformation of the font, you can try setting the hinting to none #h-none, that reduces the font quality for some sizes, but the text shape stays truer to what it should be.

@Terseus
Copy link

Terseus commented Jun 2, 2024

I've tried the gamma and contrast trick without noticing any change at all:

    vim.g.neovide_text_gamma = 0.8
    vim.g.neovide_text_contrast = 0.2

I'm sorry but while the rendering differences might seem small, the extra thickness rendered by Neovide makes the text less readable; it's a shame because this issue has been preventing me from using Neovide for about 2 years now.

Neovide may technically do it better or worse but the rendering is very different from all the other tools I've used (terminals, other Neovim GUIs, other GUI editors, web browsers) and the result is worse from an user experience POV, it's very unfortunate that this doesn't match the maintainer taste or experience.

I'm going to give up on Neovide until this gets fixed, if ever.

@fredizzimo
Copy link
Member

@Terseus
Can you open a bug report with all your system information and logs for text and contrast not working, because it should definitely have an effect on all systems. Note that it does not update until you restart Neovide.

There should be a wide range of adjustability, so it would be very surprising if nothing suits you.
0.1 Gamma, and 0 contrast should look like this
image
And 3.0 Gamma 1.0 contrast
image

It's also strange that you see thicker fonts in Neovide compared to web browsers, it has always been very similar for all Comparisions I have done with the same font and same colors (yes the background and font color matters very much). In fact we have got reports that we render the text too thin:

Both Wezterm and Kitty also renders a slightly thicker font on a dark background by default, at least on my system, check the comparisons taken here (you need to download the images and view them as the actual pixel size)

@Terseus
Copy link

Terseus commented Jun 2, 2024

@fredizzimo Sorry, my bad, I was in Neovide 0.12.2, updating to 0.13.1 made neovide_text_gamma and neovide_text_contrast work, thanks.

It's also strange that you see thicker fonts in Neovide compared to web browsers, it has always been very similar for all Comparisions I have done with the same font and same colors

I understand and respects your opinion, still Neovide renders the text less readable for me; as I stated before, maybe it's technically worse but Alacritty's font rendering creates a more pleasant experience, and when coding for +8h/day every small improvement matters.

(yes the background and font color matters very much)

I'm indeed using a dark background, if I switch to a light background the effect is not that pronounced, the font looks thinner even though there isn't really any change in how the font is rendered; it's hard to explain.

Maybe the problem lies in antialiasing?
I would like to compare it with subpixelantialias but unfortunately I can't due to #2415.

Edit: And yes, the same font (Deja Vu Sans Mono) it's rendered in Alacritty like in my browser, however in Neovide it's thicker and less taller.

I've reproduced the same problems with Fira Code and Source Code Pro.

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