Generate Xft.dpi from server dimensions at startup if not specified via configfile
Submitted by Felix Miata
Assigned to Xorg Project Team
Mozilla apps built with GTK2 have been only too happy to have their UIs obey X configuration determined via either startup xrandr or xorg.conf*. Xft.dpi has been an unnecessary optional parameter outside of Gnome-based environments.
Last year, respect for X configuration was removed from GTK. UI text sizing in Mozilla apps built with GTK3 shrunk when run in >96 DPI environments. Presumably, other apps built with GTK3 exhibit similar regressive behavior, but as a KDE and TDE user I'm not familiar with any such apps. Post-GTK-3.16, absent an explicitly configured Xft.dpi, Xft.dpi:96 is assumed. As a result, Mozilla apps run in KDE, TDE and other non-Gnome, non-96 DPI environments are not utilizing the font sizes specified for the DE's UI. Thus, UI text in GTK3 builds of Firefox, SeaMonkey and Thunderbird in the usual cases (>96) are smaller than in all GTK2 and QT apps when the DE is not Gnome-based.
Attempting to have this problem addressed via mozilla.org and gnome.org bug trackers has generated wontfix responses. What could work around the problem is as stated in $SUBJECT: generating Xft.dpi from server dimensions at startup whenever it has not been specified via configfile. It's already somewhat cumbersome to automatically force DPI to accurately reflect physical display density or some arbitrary value using either xrandr or DisplaySize. Users shouldn't need to manually configure Xft.dpi as well when the server or some startup utility could generate it automatically.
WONTFIXED Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1269274
WONTFIXED Gnome bug: https://bugzilla.gnome.org/show_bug.cgi?id=757142
Git commit responsible for behavioral change post-3.16: https://git.gnome.org/browse/gtk+/commit/?id=bdf0820c501437a2150d8ff0d5340246e713f73f