GNOME Bugzilla – Bug 551634
gtk's interpretation of DPI differs when set to 'default' vs. when force-set to the X server's DPI value
Last modified: 2015-08-16 13:24:16 UTC
Context: we've implemented a new XSETTINGS daemon for Xfce 4.6. Xfce 4.4 also didn't handle the Xft/DPI property (it only set the Xft.DPI xrdb resource), so we've added that as well. The XSettings registry[1] states that the value set for this property should be the DPI value multiplied by 1024, or -1 to use the 'default' (I assume this means X-server-specified) value. However, this doesn't work (visually). If I set Xft/DPI to -1, I get what I assume are correctly-sized fonts. 'xdpyinfo' reports my screen DPI to be 107x107, which should be correct for a 12" laptop LCD panel at 1024x768 (well, ok, 106.667). If I set Xft/DPI to (107*1024), my fonts increase in size by about 15% or so. (It's definitely not rounding error; 106*1024 is still considerably larger than -1.) The "correct" scaling factor seems to be a little bit less than 950. So... is gtk (pango?) interpreting the DPI from Xorg incorrectly when Xft/DPI is set to -1? Or is it doing something incorrectly when the DPI is forced to another value? Or are we just doing something wrong here? Running gtk 2.12.11 here, with pango 1.20.5. [1] http://www.freedesktop.org/wiki/Specifications/XSettingsRegistry
As I side note, when using "-1" here, I had problems with epiphany using gecko renderer. Some websites and the default apache folder listing show no fonts at all, as if the size was 0.
Can you reproduce that "gecko" bug in devhelp? If yes, I set the font size to 0.1 in Edit>Preferences. In a matter of facts, the higher I set the font size the smaller they get displayed :-S Or this could be completely unrelated, hard to say...
(In reply to comment #1) > As I side note, when using "-1" here, I had problems with epiphany using gecko > renderer. Some websites and the default apache folder listing show no fonts at > all, as if the size was 0. Gecko sets its own DPI via another means. That's not related to this bug.
Using pango 1.21.6, the issue still exists.
Chatting about this with some people, and experimenting a bit, I'm now convinced of the opposite. The behavior when Xft/DPI is set to -1 is incorrect, and the behavior when forcing a specific DPI value is correct. Poking around in gdk/x11/gdkxftdefaults.c, init_xft_settings(), the DPI is calculated as (display_height) * 2.54 / (display_height_mm). Then that value is multiplied by PANGO_SCALE, and then halved. Why halved?
Could some gtk developper comment on this one? Xfce 4.6 beta is bitten by this bug and it'd be nice to solve this issue before the release. Cheers and thanks, -- Yves-Alexis
Brian: screen_x11->xft_dpi = (int)(0.5 + PANGO_SCALE * dpi_double); That's "0.5 +" not "0.5 *".. it's there to get correct rounding.
Using a test program it seems that gdk_screen_get_resolution() always return -1, wether we force the DPI or not in “Appearance Settings”.
(In reply to comment #7) > Brian: > > screen_x11->xft_dpi = (int)(0.5 + PANGO_SCALE * dpi_double); > > That's "0.5 +" not "0.5 *".. it's there to get correct rounding. Gah, you're right of course. I guess I was staring at it too long. Any idea what the problem here could be, then?
breaking on gdk_pango_context_get_for_screen it seems the resolution is correctly set in gdk. gdk_screen_get_resolution() returns 125 if I force the DPI in xfce4-appearance-settings, and -1 if I don't. So maybe the problem is pango/cairo related? I have two screenshots which show the problem: http://molly.corsac.net/~corsac/xfce/dpi=-1.png http://molly.corsac.net/~corsac/xfce/dpi=125.png
This is with gtk 2.14.4, pango 1.22.2 and cairo 1.8.2
In pango/fonts.c, pango_font_description_get_size() always returns the same sizes whatever the DPI is (6144 for Liberation Sans 6) (which is not really coherent with the fact that it's not the same sizes on screen in both cases)
(In reply to comment #12) > In pango/fonts.c, pango_font_description_get_size() always returns the same > sizes whatever the DPI is (6144 for Liberation Sans 6) (which is not really > coherent with the fact that it's not the same sizes on screen in both cases) The font size returned by pango_font_description_get_size is in points and is independent of the DPI.
(In reply to comment #13) > The font size returned by pango_font_description_get_size is in points and is > independent of the DPI. Thanks. Do you know where can I find the final (displayed) size of the font, in pixels? Pango, Cairo or gtk?
(In reply to comment #14) > (In reply to comment #13) > > The font size returned by pango_font_description_get_size is in points and is > > independent of the DPI. > > Thanks. Do you know where can I find the final (displayed) size of the font, in > pixels? Pango, Cairo or gtk? Depends on what you mean by "find". Pango computes the final size and passes it down to cairo.
For the record, the same thing is reproducible with: libglib 2.18.3 libpango 2.22.3 libgtk2.0 2.14.5
Stephan Arts tracked the bug down to pango or fontconfig. http://bugzilla.xfce.org/show_bug.cgi?id=4374#c10 has all the info but basically: ---- 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) ---- Not sure how it behaves under GNOME, but…
I don't think we'll change anything here for gtk 2 at this point. And in gtk 3, we've recently reduced the amount of fallback-through-various-layers madness that is going on with resolutions.