GNOME Bugzilla – Bug 764556
regression bad font size since gtk+-3.16.x
Last modified: 2018-05-02 17:02:15 UTC
I have such display: screen #0: dimensions: 2880x1800 pixels (331x211 millimeters) resolution: 221x217 dots per inch After gtk+-3.16 all versions of gtk+ render text with too small font size. See https://578146.bugs.gentoo.org/attachment.cgi?id=429582 This is not only in emacs, also in evince and other gtk+ applications. With gtk+-3.16 all looks good: https://578146.bugs.gentoo.org/attachment.cgi?id=428892
I mean font size of main menu.
any other applications besides emacs that you have a problem with ? does setting GTK_DPI_SCALE=2 make things big enough ?
(In reply to Matthias Clasen from comment #2) > any other applications besides emacs that you have a problem with ? Yes, evince. Actually, I have no more application that uses gtk+-3.x, only evince and emacs, all other use gtk+2.x. So I suppose that all gtk+-3.x based applications affected by this bug. > does setting GTK_DPI_SCALE=2 make things big enough ? Not sure how to set it, I try it as process environment variable: "GTK_DPI_SCALE=2 evince" and no difference between "GTK_DPI_SCALE=2 evince" and "evince"
Sorry, I typoed the variable name. Please try GDK_SCALE=2 evince in a terminal. This is under X11 ?
Yes, with GDK_SCALE=2 evince looks better. Font size in menu of emacs also looks better, but appear strange bug with window size of emacs. Window size by default become huge (several screens by horizontal [at least]) after it(emacs) apply config where I set consolas font as default font. And with gtk+-3.16.7 all works fine without GDK_SCALE and emacs window size was normal. >This is under X11 ? yes, information about DPI in the first post is from xdpyinfo: screen #0: dimensions: 2880x1800 pixels (331x211 millimeters) resolution: 221x217 dots per inch depths (7): 24, 1, 4, 8, 15, 16, 32 I wrote a program that calc number of pixels in one centimetre using dot per pixels settings above, and draw such line, and measure line with ruler. So I have correct dpi settings.
Also I found one more application that uses gtk+-3.x on my machine - meld(http://meldmerge.org/) and it also affected by this bug.
I updated gtk+ to gtk+-3.20.9, the bug still here.
I do `git bisect`, the commit that introduce bug is: $ git bisect good bdf0820c501437a2150d8ff0d5340246e713f73f is the first bad commit commit bdf0820c501437a2150d8ff0d5340246e713f73f Author: Matthias Clasen <mclasen@redhat.com> Date: Tue Jul 7 20:39:45 2015 -0400 Simplify Xft setting fallback If we don't find Xft values in the X resource db, simply fall back to the values that are hardcoded in /etc/X11/Xresources anyway. Extra trickery with likely-made-up screen dimensions is not going to yield better results, and only makes for a deeper rabbit hole when debugging. :040000 040000 f989b3d72902e59bf045e3e66005745d7a740c1e f01e7be2f1fc9b3eda5768e433d76c3a97089a63 M gdk
The code is the same in 3.22. I'm dropping the severity from critical to major; I don't know whether this is really the latter either, but I don't think it qualifies as the former in any case. I'll let someone else decide about further drops.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/612.