[Webkit-unassigned] [Bug 250138] [GTK] Changing system font-scaling factor results in messy rendering of the page (Epiphany, WebKitGtk)

Tue Apr 23 20:41:58 PDT 2024

https://bugs.webkit.org/show_bug.cgi?id=250138

--- Comment #16 from Glen Whitney <gwhitneycom5 at pobox.com> ---
I am commenting as the author of https://github.com/WebKit/WebKit/pull/26938 to address https://bugs.webkit.org/show_bug.cgi?id=247980 -- the WebKit maintainers asked me to, and I would like to, address the concerns in this issue as best as possible in the course of that change to WebKit.

First, I have looked at reproducing the original concerns with epiphany. (I have not yet looked at the Wails app, but can try to if the discussion about epiphany doesn't seem to reach a resolution that appears like it will also apply in the Wails situation.)

However, it seems to me that the current version of epiphany (if I run `epiphany --version` on my laptop, it prints `Web 46.0`) has migrated to gtk 4.0. And it is my understanding that the concept of a "font scaling factor" has been removed from gtk 4.0 altogether. Indeed, if I run gnome-tweaks and change the font scaling factor (the last setting on the "Fonts" tab, under the "Size" heading) to various values and restart epiphany each time I set a new value there, epiphany looks identical regardless of the value. So I would suspect that folks affected by this issue are now seeing a different behavior than was originally reported, with respect to the influence of the font-scaling factor, i.e., that it now has no influence. If anyone concerned with this issue is able to verify, that would be great.

Nevertheless, it is clear to me that Epiphany does nevertheless currently have a scaling issue. There is still a concept of the "font dpi" in GTK4, it is controlled by the Xft.dpi GTK setting. And there is of course still a device pixel size - XWindows and/or GTK know the physical size of the display and the number of pixels in each direction. My laptop has 283 dpi, and correspondingly I have my environment set up so that Xft.dpi is 283, and I have made sure that XWindows is seeing the same pixel density.

To be completely explicit, if I execute `python3 -c 'import gi; gi.require_version("Gtk", "4.0"); from gi.repository import Gtk; print(Gtk.Settings.get_default().props.gtk_xft_dpi)'` it prints 289792, and 289792/1024 = 283.0; if I execute xrandr, the second line is `eDP-1 connected 3840x2160+0+0 (normal left inverted right x axis y axis) 344mm x 215mm` and 3840/(344/25.4) is 283.5; and if I execute `xdpyinfo | grep resolution` it prints `resolution: 284x283 dots per inch` (there is some rounding error).

In this setup, if I execute `epiphany`, it comes up by default on the webpage `https://webkitgtk.org/` and the layout seems very broken: the fonts are a reasonable size, but the entire page is jammed into a tiny section of the center of the window; I just added the screenshot prior to this comment.

Presuming this screenshot is similar to what others on this issue are now seeing, I believe the underlying difficulty is that WebKitGTK is currently not scaling the *non-font* dimensions of the layout properly. In other words, if in this same setup I visit a page like `https://katydecorah.com/css-ruler`, the size of the square with CSS side length `1in` is just over a quarter of an inch (very close to one-third of an inch, actually).

Therefore, what the PR referenced above does is arrange that the device pixel size (the common output of the xrandr/xdpyinfo resolution results) is used to scale the non-font dimensions of the layout. And then Xft.dpi is used to scale the fonts. In my setup, this has no effect on font size; as you can see in the screenshot, they were already reasonable, as epiphany/WebKitGTK was already using Xft.dpi to scale the fonts. But it roughly triples the size of the region used for the layout, so the page now renders very reasonably; I will post a screen shot right after this comment.

So once the PR lands, when a web page is viewed at the default magnification, a CSS 1in dimension should literally measure one physical inch on the screen, and as long as the Xft.dpi setting matches the device pixel density as well, a 96px=72pt font will also measure exactly 1in high on screen.

Note that one thing the proposed PR does _not_ do is create an effect of Xft.dpi on the non-font dimensions of a web page. The non-font-related dimensions will correspond exactly to the device pixel density as reported by GDK, which stem from the resolution as reported by xrandr/xdpyinfo, possibly adjusted by the overall integer scaling factor GDK_SCALE. That keeps 1in in CSS pegged to one actual inch on screen, which HTML5 and CSS standards would seem to require (and which WebKitGTK currently fails to do when the device pixel density is anything other than 96 dpi).

In other words, if in your setup Xft.dpi does not match the observed device pixel density, then layouts will not necessarily match their original design, with text being larger or smaller than the space allocated for it. But I would suggest (a) that's exactly the expected behavior under GTK -- for all other GTK applications, changing Xft.dpi away from the actual device dpi changes just the font sizes, not the layouts, often leading to broken-looking layouts (e.g., button labels not fitting in their buttons), and (b) as long as you create a setup in which Xft.dpi and the reported device pixel density match, the referenced PR will solve the issues reported here. I do not think it would be semantically consistent, or consistent with CSS standards, for changing Xft.dpi to bleed over into changing the non-font dimensions of web pages.

So looking forward to any feedback that anyone concerned with this issue may have, and if there are suggestions that would impact the PR that would receive the approval of the WebKitGTK maintainers, I would be happy to incorporate them.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20240424/0fdc49c8/attachment.htm>