GNOME Bugzilla – Bug 773494
Composer doesn't respect dpi settings
Last modified: 2016-12-05 11:45:29 UTC
To use evolution on a high density screen, which are now popular in newer laptops, and still get reasonably large buttons one had to set GTK environment variables for example like: #export GDK_SCALE=2 #export GDK_DPI_SCALE=0.5 See https://wiki.archlinux.org/index.php/HiDPI for more information. With more recent versions of evolution/GTK this is no longer necessary, as evolution respects the value set for Xft.dpi in .Xdefaults. In my case, setting this to Xft.dpi: 170 gives a nicely usable user interface, in which just the icons are a bit small, but all buttons are reasonably large. In fact, since the most recent update, setting GDK_SCALE and GDK_DPI_SCALE to values !=1 leads to all sorts of other problems, like context menus being placed in the wrong positions, but this is a separate bug, which I will report independently... This bug is about the following: The composer window doesn't respect Xft.dpi, leading to a painfully tiny font in the email composer, thereby seriously impacting usability. This can be verified as followed: * Put 'Xft.dpi: 50' into .Xdefaults and start evolution and open a new email -> everything is tiny, except the font in the mail body of the composer window * Put 'Xft.dpi: 200' into .Xdefaults and start evolution and open a new mail -> everything is gigantic, except the font in the mail body of the composer window Expected behavior: Like all other text based elements of the UI, also the composer html view should respect the dpi setting.
Thanks for a bug report. I've not much idea yet, I only want to add, for the reference, the other related bug report is bug #773496.
The composer fonts are fully managed by WebKitGTK+. What is your exact version of the WebKit2 (possibly webkitgtk4), please? I recalled of an old bug https://bugs.webkit.org/show_bug.cgi?id=82889 though I do not know the state of the webkitgtk+ 2.14.1 in this regard.
(In reply to Milan Crha from comment #2) > The composer fonts are fully managed by WebKitGTK+. Unfortunately WebKit expects text sizes in pixels, which means you have to compute it yourself or you'll get a crap result. It's horrible and I think it's a WebKit bug, but that's the API we have. You'll need to use deprecated GdkScreen APIs. See for an example: https://git.gnome.org/browse/epiphany/tree/embed/ephy-embed-prefs.c#n209 We've just been copying that around between each application using WebKit2 (Epiphany, Devhelp, Yelp, ...).
(In reply to Michael Catanzaro from comment #3) > (In reply to Milan Crha from comment #2) > > The composer fonts are fully managed by WebKitGTK+. > > Unfortunately WebKit expects text sizes in pixels, which means you have to > compute it yourself or you'll get a crap result. It's horrible and I think > it's a WebKit bug, but that's the API we have. You'll need to use deprecated > GdkScreen APIs. See for an example: > > https://git.gnome.org/browse/epiphany/tree/embed/ephy-embed-prefs.c#n209 > > We've just been copying that around between each application using WebKit2 > (Epiphany, Devhelp, Yelp, ...). We are using the same workaround for EWebView (all web views in Evolution, but not used for composer), but we are missing the same workaround for "default-monospace-font-size" and "minimum-font-size" properties in EWebKitEditor.
Fixed with the following commits: Bug 773494 - Composer doesn't respect dpi settings Normalize the font size when setting the "default-monospace-font-size" and "minimum-font-size" properties of WebKitSettings (as we do for EWebView). commit a5759a8 in the master branch for Evolution 3.23.2+ commit 73ca4ed in the gnome-3-22 for Evolution 3.22.2+ I was not able to test it as modifying .Xresource or .Xdefaults files didn't make any difference (reloading them with xrdb or restarting the whole machine) on my F25 with Gnome Shell. If someone could test the commit and give me a feedback it will be much appreciated.
Thanks for attacking this so vigorously! Not sure if this is still relevant: My libwebkit2gtk version is 2.14.0-1 from Debian unstable. I don't have the necessary build environment set up to test the proposed fix, so would be grateful if somebody else could try.
I can confirm that with evolution 3.22.2-1 and libwebkit2gtk 2.14.2-1 from Debian unstable this is almost fixed. The font size is now scaled correctly. Thanks! However, the cursor thickness is not the same as in other text fields. On my machine it is so thin that it is quite hard to see where it is. In other text fields the cursor is noticeably thicker. I hope reopening this bug, rather than submitting a new one is the correct thing to do...
That's not Evolution's fault, but a WebkitGTK+ one. Can you please take a screenshot or record the screencast?
I have opened a bug with webkit here https://bugs.webkit.org/show_bug.cgi?id=165371 and uploaded a screenshot there.