[Webkit-unassigned] [Bug 259309] New: GNOME text-scaling-factor (Large Text accessibility option) isn't respected

[bugzilla-daemon at webkit.org]

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

            Bug ID: 259309
           Summary: GNOME text-scaling-factor (Large Text accessibility
                    option) isn't respected
           Product: WebKit
           Version: WebKit Local Build
          Hardware: Unspecified
                OS: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKitGTK
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: calvin.walton at kepstin.ca
                CC: bugs-noreply at webkitgtk.org

See this Epiphany issue: https://gitlab.gnome.org/GNOME/epiphany/-/issues/1458

GNOME provides a "text-scaling-factor" configuration to adjust the size of fonts in applications. This is used to implement, for example, the "Large Text" accessibility setting.

Gtk exposes this via the Gtk Settings "gtk-xft-dpi" property: https://docs.gtk.org/gtk4/property.Settings.gtk-xft-dpi.html
where the value returned is either -1 to "use the default value", or an integer which is equal to the text scaling factor × 96 (or 72 on macOS) to convert to "DPI", then multiplied by 1024 to convert to fixed precision. Note that this "DPI" value is not affected by display scaling; if someone has a text-scaling-factor of 1 on a monitor configured with 200% scaling, this property will still have the value 96 (not 192).

(In Gtk 3 this was also available via `gdk_screen_get_resolution`, but the `gtk-xft-dpi` property will work on both Gtk 3 and 4)

For a point of comparison, Firefox uses this value to adjust the `window.devicePixelRatio` value, performing scaling of the entire web content. For example, on a display with 200% scaling and text-scaling-factor of 1.25, the resulting devicePixelRatio will be 2.5. But they don't use the scaling value directly; instead they quantize "smallish" values to either 1.0, 1.25, or 1.5: https://hg.mozilla.org/mozilla-central/file/35e42e5979dac0b99828194869d5dc00365b37fb/gfx/thebes/gfxPlatformGtk.cpp#l458 (they don't support scale values < 1.0 at all).

I'd say that doing quantization like this is probably not desirable in WebKitGTK. People using GNOME's large text mode will already get exactly 1.25, and people using an X server with custom DPI, or who have manually set a custom text-scaling-factor in GSettings (like me), would prefer that the exact number (or as close as possible) to what they have set is used. This will help match other GNOME applications better.

I personally prefer the behaviour of scaling the entire page (like zoom) over changing text size only, especially since this is less likely to break website layout.

Note that if you are manually drawing a scrollbar which is styled to look like Adwaita, the scrollbar should not be scaled (otherwise it won't match size of other Gtk widgets) - this is a bug that Firefox hit :) https://bugzilla.mozilla.org/show_bug.cgi?id=1699930

-- 
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/20230718/fc07556f/attachment.htm>