Hide Forgot
When the GNOME font scaling factor (org.gnome.desktop.interface text-scaling-factor, "Scaling Factor" in Tweak Tool under Fonts) is not equal to 1.0, after some time logged in under GNOME, newly-launched Qt5 applications will start with tiny fonts (approx. 1/3 height and 1/3 width, so ~1/9 size overall). The value of text-scaling-factor doesn't seem to matter, greater or less than 1 seems to result in the same tiny size. QGnomePlatform doesn't seem to be the culprit, as uninstalling it or unsetting QT_QPA_PLATFORMTHEME does not resolve the issue. Setting the scaling factor to 1.0, then launching the application results in normal font sizes. If QGnomePlatform is installed, subsequently changing the scaling factor after launch works fine as well. Logging out then in again fixes the issue for a while. I've tested on several Qt5 applications and all have the same issue, including a simple 'Hello World' Qt5/C++ test application I created. I can't find any resident shared libs, relevant user config. files or anything obvious using strace that would explain the behaviour.
Hello Stephen, sorry for taking so long to answer. Is this problem still present? I just tried font scaling in GNOME Tweak Tool and it seems the fonts scale up, not down. However, the scaling is still not the same as in GNOME apps.
No, it seems to have been fixed somewhere. For reference, (in case it or a similar issue returns) here's all the info I found at the time: It was somehow related to the *real* DPI of my screen being exposed after a while of being logged in, instead of the 96 DPI value that apparently "should" be exposed¹ (e.g. as visible with xdpyinfo). Since my display is a large TV screen 2 metres away, exposing its real and low DPI value (approx. 30 DPI) resulted in QT5 apps drawing fonts at an unusable size. I couldn't figure out any way of getting the display manager (GNOME Wayland) to revert to reporting 96 DPI, but a workaround was to set the QT_FONT_DPI environment variable, e.g. QT_FONT_DPI=96 smplayer ¹https://bugs.freedesktop.org/show_bug.cgi?id=23705
This bug has returned; I'm seeing it on F27 with Qt5 apps, which are currently using Qt 5.9.2. As before, the bug kicks in some time after being logged in; as before, setting QT_FONT_DPI=96 temporarily fixes it for a given application launch. Also as before, when the bug appears, the xdpyinfo-reported DPI is physical-reality correct but "wrong" in the "official stance is ignore reality, we'll pretend everything's 96 DPI" sense: $ xdpyinfo | grep dots resolution: 30x30 dots per inch I'll confirm on next log out/in that this reverts to reporting 96 DPI initially. I'm guessing that this bug doesn't really belong in Qt, and is a result of Qt relying on the reported DPI that xdpyinfo also obtains/uses. Any suggestions for which component it should be move to instead?
I'm guessing this is actually a problem with Mutter since I'm using Wayland, and presumably Mutter is responsible for reporting DPI to X clients in that case. Upstream bug speculatively filed there: https://bugzilla.gnome.org/show_bug.cgi?id=790537
Hi, I'm seeing similar issues with the text/font scaling factor on non-standard DPI screens (!= 96dpi ... I'm at 130dpi). What I typically do to bypass the hard-wired 96dpi baseline of Gnome: I'm setting the desired font size (in absolute numbers) and adjust the font/text scaling factor until the Xft.dpi number as reported by 'xrdb -q' lines up with the actual display as reported by xdpyinfo. (Took me a while to recognize that Gnome is dynamically adjusting the DPI value based on the font scaling factor) This way everything "Gnome/Gtk" is consistent in terms of font sizes. (I'm just using a tweaked Shell theme on my laptop to get smaller fonts in the title bar, as the CSS configured font is basically too large for a small laptop display). The issue comes from QT5 + GTK+ theme engine (fc27, qt5-5.9 in my case), and how it dynamically translates the font scaling factor to Qt5 apps when running on a Gnome desktop session. The resulting font size is completely off. The interesting fact, which blames the Gtk+ them engine of Qt5: Once I set the Xft.dpi value as reported by "xrdb -q" on the environment via QT_FONT_DPI (as a rounded integer number; QT doesn't accept real values for QT_FONT_DPI), the font size on Gtk and Qt lines up. >> QT GTK+ theme engine make something wrong calculating the DPI value based on the font scaling factor on it's own. It's obviously not utilizing the (correct) value set by Gnome (dynamically) for the Xresource Xft.dpi. Toby
Correction: I did some further testing, and the problem is that Qt5+Gtk+ engine honors the font scaling factor as well as the adjusted Xft.dpi Xresource value (!). This way Qt5 apps will effectively see the square of the font scaling factor. Nonsense! To get QT5 apps font scaling in sync with Gtk, it's required to fix the QT_FONT_DPI value to 96dpi similar to Gtk/Gnome. The absolute size is still way off from being real "points", but at leasts everything is in sync. Further, Qt5 with correct DPI value applied (via QT_FONT_DPI) scales to correct absolute font sizes, whereas Gtks/Gnomes calculated DPI value (set for Xft.dpi dynamically) is obviously not correct. Because when adjusting the font scaling factor to get Xft.dpi=130dpi (the dpi value of my screen), Gtk applications do not provide anything close to the correct absolute font size (measured on screen), but Qt5 for QT_FONT_DPI=130 does! What a shame .... Qt5 does obviously a way better job. Regards, Toby
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still happening on Fedora 28. I haven't moved to F29 yet on the relvant machine (i.e. the one with the very low real DPI because it's a large TV).
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.