yast / yast-installation

YaST module installation
http://en.opensuse.org/Portal:YaST
GNU General Public License v2.0
16 stars 44 forks source link

Reuse existing Qt scaling calculation fof xterm font size #1086

Closed hramrach closed 1 year ago

hramrach commented 1 year ago

Problem

Different convoluted calculations for Qt font size and xterm font size

https://github.com/yast/yast-installation/pull/1085#issuecomment-1544181887

Solution

Use Qt scaling factor to to multiply a base font size

shundhammer commented 1 year ago

Thank you, but I deliberately chose not to do it like that: It starts new interdependencies between unrelated things. We have the Qt scaling (which changed several times before, so chances are that it may change again with a newer Qt version) and the xterm font size.

I deliberately chose to keep both things separate so they are more robust about future changes. We have a bad history with that.

Also, this invalidates all testing that I did; fiddling with the inst-sys is no fun, and it's finicky at the best of times.

hramrach commented 1 year ago

To the contrary.

Both xterm font size and Qt scaling set the apparent font size, it's the same thing, not different thing.

Setting the xterm font based on the Qt font size makes it robust against future changes, while your approach of separate calculation makes it fragile.

If the installer font size is changed in the future the xterm font size should follow to match it, not remain some random value. If there is a reason to change the font size in the installer the same applies to xterm.

Nonetheless, even with your approach of setting random font size it's much better than what the default font size is.

shundhammer commented 1 year ago

No, those two values have nothing to do with each other.

Did you try the values? Did you try what the minimum font size of 12 looks like in, say, a standard VM installation that typically uses a resolution of 800x600? You will find that the xterm window won't fit on the screen. That's why my version starts with 10.

On a normal resolution (which today means full HD or a little larger; 1920x1080 or 1920x1200), 12 is a good value; it's well legible, but it's not too huge.

On HiDPI (4k), I used your suggested value of 14. Since I don't have a HiDPI display, I can't test it.

Some day we'll get 6k and 8k. How large the font needs to be remains to be seen. But a font size of 14 will still be better than xterm's built-in 1990s pixelated micro-font.

hramrach commented 1 year ago

No, they are the very same thing, calculated differently.

Scalable fonts can be rendered at any size above some minimum which would be something like 9pt at 96 DPI for DejaVu.

However, toolkits like Qt also have non-font elements like checkboxes and button borders which are typically only available as bitmaps because nobody cares enough about HiDPI users to re-draw them as vector graphics.

Which brings this 'scale factor' - rendering the UI at certain screen size, and then scaling everything up to bigger screen. Which also brings the stepping problem - scaling only works reasonably for certain ratios, not arbitrary ratio, unlike font rendering.

That means with scaling factor working correctly on any screen size everything is proportionally the same except for rounding errors which are dominated by the scaling ratio stepping, and rendering glitches.

If you disregard rendering glitches you don't really need 6k and 8k screen to verify how the installer will look, it will be the same as at 4k. So long as everything works for screen sizes between 1.0 and 1.25 scaling and the calculation is correct, and gives same results between 1.25 and 1.5 again you don't really need to see all the other bigger sizes.

If the font size of the xterm window is scaled together with the installer UI it will match the proportions of the rest of the installer, and will be the same at any bigger resolution. And unlike scaling there is little reason for rendering glitches there.

"Did you try what the minimum font size of 12 looks like .." where did you get that? The minimum size up to 96 DPI is 10, exactly the same as it was before this change. What this change does is that it does not cap the size to 14 but rather scales it up to match the rest of the installer. If there is reason to scale the installer up or down the same applies to xterm. That you cannot connect the dots between these two functions that you both authored is exactly the reason for these to not be two separate functions but rather one function so that anyone looking at the code is aware of all the font sizing going on.