Bug 94160 - Zoom scale should depend on resolution reported by xdpyinfo not by xrdb
Summary: Zoom scale should depend on resolution reported by xdpyinfo not by xrdb
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected)
Hardware: x86-64 (AMD64) Linux (All)
: medium enhancement
Assignee: Not Assigned
Depends on:
Blocks: Desktop-Integration
  Show dependency treegraph
Reported: 2015-09-12 13:22 UTC by nagmat84
Modified: 2019-08-31 15:59 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:
Regression By:


Note You need to log in before you can comment on or make changes to this bug.
Description nagmat84 2015-09-12 13:22:08 UTC
With KDE (and perhaps some other desktop environments) there are two independent, different resolution values that affect how the GUI is scaled.

The first value is reported by "xdpyinfo | egrep -i resolution" and depends on the actual screen size (at least if the X server can determine it). In my case it returns

resolution:    209x209 dots per inch

The second value is reported by "xrdb -query | egrep -i 'xft' and can be overwritten by KDE's "force font dpi option". In my case it results in

Xft.dpi:        120
Xft.hinting:    -1
Xft.rgba:       none

The "force font dpi option" is very often necessary to work around problems in some application that do strange GUI scaling for very high DPI values (firefox is a prime example).

Anyway, LibreOffice looks totally right on my screen with these settings but there is a minor drawback. If I set the zoom to "100%" a DIN-A4 page does not has the size of an actual DIN-A4 page but is too small. If I set 175% the DIN-A4 has the correct size. Nothing of this is very surprising, because 209/120 = 1.74.

However, it would be nive, if LibreOffice would proceed as follows:

(1) For GUI styling (menu bars, dialogs, etc.) use the resolution as being reported by xrdb. (This is already the case.)

(2) But use the resolution as reported by xdpyinfo to scale/zoom the actual page content.
Comment 1 Buovjaga 2015-09-24 06:27:11 UTC
Sounds reasonable -> NEW