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 height specification in pixels #2010
Comments
Hi, thanks for reporting! https://neovide.dev/configuration.html#font and |
This issue is also missing some other details. Like
That said, the scaling appears to be slightly buggy in X11, but not in Wayland. In Wayland it's totally consistent with Kate for example. But on X11, the text size can be either bigger or smaller depending on which scaling your are using, and Neovide is displaying it at the wrong size. I don't know what's the cause for this, but it's a well known fact that X11 has quite broken HiDPI support. |
Ah, I see, winit reports a scale factor of 1.1667, although I have it set to 100% in X11 KDE Plasma. So that explains the difference. |
For the scale factor on X11 it appears like winit is doing it’s own calculation, see rust-windowing/winit#2231. Apparently it can be overridden by WINIT_X11_SCALE_FACTOR=1, but I have not tested it. Yes, that makes the size consistent with Wayland and Windows. But not with Kate on X11, which renders the text slightly bigger than Kate on Wayland. |
Xfce 4.18, with AwesomeWM replacing the default window manager.
X11, because AwesomeWM doesn't do Wayland, and because NVIDIA.
None, as far as I'm aware. On all systems, the Xfce Appearance preferences have DPI set to 96, and no scaling is applied via xrandr.
A discussion in the SkiaSharp repo led to this message on the Skia mailing list suggesting that, yes, the font size is effectively specified in pixels. Granted, this was three years ago. There's also an attempt in Neovide to convert from points to pixels here using a fixed ratio (96 / 72): neovide/src/renderer/fonts/font_options.rs Lines 147 to 166 in 598f777
But, again, this doesn't appear to actually be the case -- |
That's not just an attempt, that's the standard. This value is then scaled to physical pixels using the desktop scaling factor here https://github.com/neovide/neovide/blob/598f7779a404b729de33d748780e5be0de0197d5/src/renderer/fonts/caching_shaper.rs#L73C43-L73C43, On a modern desktop you set the scale factor on each monitor so that you have a consistent font size on all of them, no matter the actual physical DPI they might have. I believe the problem you are describing is caused by a wrongly configured scaling factor, or that it's not passed on to winit. And as I explained earlier, I believe their calculations are flawed. But that does not matter since you can set it to whatever you want with |
(...many Google searches later...) Ah, here we are:
I don't have Adding (This is not the first time I've bumped into puzzling DPI issues...) |
Great that you got it working, I think we need a FAQ entry about the And it looks like the Wayland documentation is wrong, Winit 0.28 added support for fractional scaling, and I'm pretty sure it worked when I tested it. |
Added a faq. Closing |
This issue appears to have resurfaced. After explicitly setting
The factor 1.1667 doesn't seem to make any sense -- it can't be derived from the physical DPI of either of my monitors. If I launch neovide with the environment variable This feels like a regression in |
It's quite possible, they switched x11rb instead XLib The calculation is done here https://github.com/rust-windowing/winit/blob/master/src/platform_impl/linux/x11/util/randr.rs And although, it does not make sense to me, you would get a 1.1667 scale factor if your physical monitor is 112 DPI, which sounds very plausible (112/96 = 1.667). |
Describe the bug
The docs and code suggest that specifying a font's size using the
h
parameter (e.g.:se gfn=ProFont:h9
) describes the font's height in pixels. This does not appear to be the case. Depending on the display's DPI, a given font size will yield significantly different results. This happens regardless of the system display resolution as reported byxdpyinfo
.My guess is the problem lies in the Skia library, since Neovide doesn't appear to determine display DPI, nor make adjustments to the user's requested font sizes.
To Reproduce
Steps to reproduce the behavior:
gfn
on each machine/display to the same font face and size.Expected behavior
The rendered fonts should be of the same pixel dimensions, regardless of display DPI; or at least respect the user-specificed DPI in the system preferences. (If you want font size described in a resolution-independent manner, then you should have a different specifier (
p
?) to describe the font's size in points.)Screenshots
All windows used the font Iosevka Extended.
h9
on a 109 DPI display:h6
on a 145 DPI display:h5
on a 210 DPI display:For reference, here's the Kitty terminal emulator, with
font_size 5
on a 210 DPI display. It looks exactly as tiny on the other DPI displays as well:Desktop (please complete the following information):
Please run
neovide --log
and paste the contents of the.log
file created in the current directory here:neovide_rCURRENT.log
Additional context
The text was updated successfully, but these errors were encountered: