Ok, I'll try to summarize here. Using packages on http://mocha.foo-projects.org/~stephan/alpha/ I have DPI problems. I have a SXGA+ (1400×1050) 14" screen, so my native DPI settings is 125. If I let the default (use -1 in Xft/DPI property), I have various problems: - gtk fonts are much tinyer than with “default” DPI in 4.4 - some fonts are not readable at all (in gecko, on xfce.org websites, see http://molly.corsac.net/~corsac/xfce/ and on apache folder listing) If I run xfconf-query -c xsettings -p Xft/DPI -s 125, I end up with “48” in the “appearance settings” window, and fonts seem to look ok, at least in gtk If I set 125 in “Appearance Settings” window, gtk font are *huge*. So there is at least two problems (currently, but I can't say the correct svn revision I'm talking about :) ): - non consistent settings between xfconf-query/xsettings.xml and the Appearance Settings window - problems with some fonts (gecko but some others too I guess) Plus the “scaling” stuff which look weird to me: why one needs to scale anything? Cheers, -- Yves-Alexis
(In reply to comment #0) > - non consistent settings between xfconf-query/xsettings.xml and the Appearance > Settings window This *could* be related to non-consistend xfconf/xfce4-settings package. I'll retry tonight to rebuild both of them with latest packages on mocha.
FTR the GNOME bug is at http://bugzilla.gnome.org/show_bug.cgi?id=551634
We had a little debug session on irc about the font size problems. Gecko workaround (from mr_pouit): - In firefox, go to about:config and set layout.css.dpi to -1 (0 is th default) - In devhelp, put the same setting in ~/.gnome2/devhelp/mozilla/Devhelp/prefs.js Someone on #gtk+ suggested to jeromeg: Put a breakpoint in gdk_pango_context_get_for_screen(), see what dpi is set there. That will tell you whether your issue is with Pango/Cairo or with XSettings/GTK+ and he also said "There's no halving. "0.5 + " is not "0.5 *" And he basically said that they would not spend time debugging this... I set a breakpoint for gdk_pango_context_get_for_screen() and launched devhelp. If I don't set my dpi, I get a resolution of -1, and the dpi value I put in the settings manager otherwise. gdk_pango_context_get_for_screen() calls pango_cairo_context_set_resolution () with the dpi value. The docs say: "A 0 or negative value means to use the resolution from the font map" So everything sounds ok, but nonetheless I get fonts with size 0 when my dpi is set to -1. Interestingly I and mr_pouit just have this problem with gecko apps, while Corsac gets very differently sized fonts also in thunar and pidgin. If he doesn't set the dpi value, then his fonts become very small. See: http://molly.corsac.net/~corsac/xfce/dpi=-1.png http://molly.corsac.net/~corsac/xfce/dpi=125.png I wrote a little test app which checks what resolution gtk thinks is set: http://dsp.mcbf.net/dpi-test.tar.gz
Adding a little debugging output to gtk, I noticed that in gdk/x11/gdkxftdefaults.c, _gdk_x11_get_xft_setting () is never called with name having prefix "gtk-xft-". So init_xft_settings () is actually never executed, which could explain why it works when a specific dpi value is set.
(In reply to comment #4) > Adding a little debugging output to gtk, I noticed that in > gdk/x11/gdkxftdefaults.c, _gdk_x11_get_xft_setting () is never called with name > having prefix "gtk-xft-". So init_xft_settings () is actually never executed, > which could explain why it works when a specific dpi value is set. For clarification, in 4.6 the init_xft_settings is _never_ executed, no matter if a custom dpi value is set or not. I also tested: In 4.4 with system default dpi settings, there is very early on a call to _gdk_x11_get_xft_setting with name=gtk-xft-dpi . I'm assuming the same happens when a custom dpi value is set (but I haven't tested it). Why is this different from 4.6?
Ok, this bug is really nasty, nobody really know what happens, nor here nor on the GTK size. I don't really know how to debug this, so if nobody knows either or can point me to the right direction, it'll be in 4.6.0. If it is the case, we will need to address this in the release notes, README or something like that, so users with high DPI display don't cry, saying Xfce 4.6 is crap. (but it'd be better if we could find out what, in the end, causes the problem :/ ) I think it's a 4.6 blocker in either way.
No, we're not blocking 4.6 for this. But perhaps we should add something evil to xfsettingsd to force Xft/DPI to the 'correct' value based on monitor size for the case that the setting is -1. Stephan, what do you think?
*** Bug 4869 has been marked as a duplicate of this bug. ***
Ok, atm (rc1) when the “default” is selected, 96 is selected. I think it'd be better to try autodetection of X value and use that if possible. If not, fallback to 96. (and anyway display the value used, greyed, so that user know which DPI is effectively used). It really seems that -1 is not a valid value in Xsettings, but until GTK+ guys answer us, we're stuck on this :/
When DPI == -1, Pango uses fontconfig to retrieve the DPI settings. That this does not work right, is clear... But I don't know if this problem should be solved in Pango or fontconfig. (eg, use X11 instead of fontconfig, or let fontconfig return the correct DPI settings) Either way, we should not hack around this in xfsettingsd and let the problem be solved where it is should be. Fontconfig and/or pango. I will keep this bug around to remind me of the issue, but it won't be one which should be fixed in xfce code.
Created attachment 2175 Proposed patch The tricky part is obviously if you have a multiscreen layout, which can screw up DPI calculation entirely, But then, the idea of having one single DPI for the whole screen that can be made up of different monitors with different DPI each is wrong in the first place. To avoid the problem, the patch takes the smallest DPI value in X and Y. That will break if you have 2x2 multiscreen layout, but hey, we are talking about sane defaults here, not fixing the issue for all and any situation (this is why the setting is a settings, so ppl can adjust for the corner cases!)
Wow, thanks If it applies against rc1 I'm testing that tonight and report back asap.
I tested the patch, but made the following adjustments to make it work a little better (imo): - Add a minimum DPI of '50' to the .glade file and a 'default' of 96. - set the spinbutton value to 96 when the checkbox is toggled to active, this makes sure the DPI settings won't default to an unreadable 50. (or -1 when that was the old xfconf value, making 0 the first value that works when increasing the value) What do you think? It is not perfect, but it makes the dialog better usable.
Ok, now that the patch has been committed, I guess we could close this one?
Sure :-)