Font is rendered slightly larger than it should be

[sbogomolov]

• Sway Version: 1.6

• Configuration File: https://gist.github.com/sbogomolov/3ff674cd17436dde62ba437c709ef9cb

• Description:

  • Set monospace font to Fira Code
  • Set font size to 10 in configs for sway and terminal emulators
  • Start sway
  • Compare font size in different terminal emulators (foot, alacritty, termite) with the font size in the title bar and swaybar.
  • Font size in sway title bar and swaybar is slightly larger than the font size in terminal emulators.

Screenshot showing the issue.

As a workaround I set the font size to 9.7 in sway config.

[schauveau]

I switched to foot a few weeks ago and I also noticed that the font size are slightly off. However, I am tented to blame foot more than sway. This is because terminals are true monospace applications that work by rendering each individual character in a fixed size cell. Regular applications like sway probably work quite differently even for monospace fonts.

There is also the issue of screen dpi vs screen scaling. The root terminal has an option dpi-aware to scale the font according to the screen dpi or to the screen scale factor (as set by 'output scale' in sway?). I am not sure how to get the screen dpi on wayland but on my laptop xdpyinfo | grep 'resolution:' returns 96x96 and the foot font scaling varies a lot with and without dpi-aware.

[sbogomolov]

@schauveau thanks for the input! I have disabled the dpi-aware for foot and also use scaling of 1.0. I've noticed this not only with foot though. I've tried alacritty and termite as well. Even bemenu renders fonts the same way terminals do. For now it seems that only sway renders them slightly larger.

I have also compared it to i3 (which is where I am coming from) and it did not have this issue. The same monospace font in i3 is rendered the same both by i3 and by termite. Not sure this comparison is fair, but the difference was quite noticeable when I switched from i3 to sway.

[schauveau]

Looking at your screenshot and accounting for the missing column and slightly different alignments, I would says that the font in Sway is slightly stretched vertically. The horizontal scaling looks fine. Assuming that this is effectively a bug in Sway, my guess would be that Sway incorrectly computed the vertical dimension of the text texture (forgot to remove the space between the lines?).

[sbogomolov]

That is a very good observation! I did not notice the missing column. Now when I look at it, it does indeed looks like the font rendered by sway is stretched vertically.

[schauveau]

Looking at the source:

• the text size is computed in get_text_size() of common/pango.c
• the text texture is rendered with cairo in update_title_texture() of tree/container.c
• the text texture is displayed in render_titlebar() of desktop/render.c and more specifically in the piece of code starting here:

  sway/sway/desktop/render.c

  Line 546 in 3bf9919

  if (title_texture) {

At line 594, the texture_box variable is combined with output->wlr_output->transform_matrix to get a projection matrix. I do not know enough but I would not be surprised if the vertical scaling was introduced here.

Maybe because the pixels on your screen are not perfectly square? What DPI do you have in xdpyinfo?

[sbogomolov]

This is what I get:

$ xdpyinfo | grep 'resolution:'
  resolution:    96x96 dots per inch

[schauveau]

Another suspicious part is the scaling at lines 557 and 558. At first, I ignored those operations because they affects both the width and height identically but then I noticed that the results are integers. That means that if rounding occurs then the smallest (so the height) is likely to be affected more than the biggest (the width). That could cause the height to change by up to 1 pixel which is significant.

I am not a sway dev by the way so I think that I will stop here. That's quite interesting but unfortunately I have other things to do.

[sbogomolov]

Thanks for looking into it. I'm sure that your insights will help in fixing this.

[dnkl]

I switched to foot a few weeks ago and I also noticed that the font size are slightly off. However, I am tented to blame foot more than sway

Foot's default behavior is to scale fonts using your monitor's true DPI, as long as the scaling factor is 1. If you have set a scaling factor, then foot will do what almost all other applications do: assume a DPI of 96, and instead scale the fonts using the scaling factor.

This can be changed to either always using the monitor DPI (dpi-aware=yes), or to always use the scaling factor (dpi-aware=no).

I'm not aware of any Wayland generic way of getting the DPI. But foot will tell you if you start it from another terminal:

...
info: wayland.c:1234: eDP-1: 1920x1080+0x0@60Hz 0x42ED 15.33" scale=1 PPI=147x154 (physical) PPI=147x154 (logical), DPI=143.66
...

In the example above, the relevant numbers are: 1920x1080, 15.33" and the DPI: 143.66. Use e.g. https://www.calculators.tech/dpi-calculator to check the numbers.

This is what I get:

$ xdpyinfo | grep 'resolution:'
  resolution:    96x96 dots per inch

96 is almost certainly not your monitor's actual DPI.

DPI is hard. It's definition has been butchered by X11. As a result, almost all applications ignore the true DPI. This is why foot looks different compared to many other applications.

You might find this interresting: https://codeberg.org/dnkl/foot/src/commit/4a945ce4661bbe3358216138c24e9faacabd1cd1/README.md#user-content-dpi-and-font-size

[emersion]

There's been discussion about a protocol to provide UI scaling information to Wayland clients: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/34

[schauveau]

@emersion Does Sway make use of UI scaling information that are not given to the client? If so that could explain why sbogomolov titles are slightly stretched vertically?

[emersion]

No, Sway doesn't do any magic with DPI. Sway should always scale surfaces with the same ratio for the x and y axes.

[sbogomolov]

@dnkl I am using foot with dpi-aware=no and my scaling factor is 1.

The point @schauveau was making about int truncation does sound like a lead. When I change the font size in sway config to 9.7 I'm getting the font size which is very close to what I see elsewhere. So by going from 10 to 9.7 I'm reducing the font height, but not the font width.

This is how it looks like with font size of 9.7 in sway config: screenshot.

[dnkl]

@sbogomolov which version of fcft do you have? In versions prior to 2.4, fcft truncated the FontConfig provided pixel size when setting the font size in FreeType. In 2.4 and up, fcft instead rounds it.

In other words, if FontConfig tells us to use a pixel size of 13.7, fcft < 2.4 would tell FreeType to load the font at 13px, while fcft 2.4 will use 14px.