Created attachment 147586 [details]
screenshot showing the problem
When using SAL_USE_VCLPLUGIN=qt5, all fonts, tooltips, toolbar icons etc. are way too large. Only the menu bar is the right size. (See attached screenshot).
This is on X11 at a resolution of 1920x1080 in Plasma 5.14.4 (Qt 5.11.2). Other Qt/KDE applications look right.
SAL_USE_VCLPLUGIN=kde5 is better (though not 100% right, will file another report for that), SAL_USE_VCLPLUGIN=gtk3 looks perfect.
FWIW, report about the possibly related problem with SAL_USE_VCLPLUGIN=kde5 is bug 122133
Interesting phenomenon, which I can't reproduce.
It's not related to bug 122133. One eventually related bug is 121283.
The menu bar is a real QMenu, so I guess that's the reason why it's font is ok.
Currently I have no idea what might force icon and font scaling in LO. I guess it's something DPI related, but have currently no idea how to reproduce this.
Is this some small screen like a 10" notebook, which might result in a high DPI value? What's your output for xdpyinfo? The interesting part looks something like:
dimensions: 1920x1200 pixels (508x317 millimeters)
resolution: 96x96 dots per inch
I'm setting the bug to NEEDINFO. Please change the bug back to UNCONFIRMED when you have provided the requested information.
Please also include the following stuff:
- check the possible settings mentioned in http://doc.qt.io/qt-5/highdpi.html (paragraph: High DPI Support in Qt), especially the environment variables of the soffice.bin process via /proc.
- provide the kwin support information via "qdbus org.kde.KWin /KWin supportInformation".
This is on a 24" desktop screen.
xdpyinfo doesn't say anything too surprising.
dimensions: 1920x1080 pixels (508x285 millimeters)
resolution: 96x96 dots per inch
The only relevant bit in /proc/$(pidof soffice.bin)/environ is
$ qdbus org.kde.KWin /KWin supportInformation
KWin Support Information:
The following information should be used when requesting support on e.g. http://forum.kde.org.
It provides information about the currently running instance, which options are used,
what OpenGL driver and which effects are running.
Please post the information provided underneath this introductory text to a paste bin service
like http://paste.kde.org instead of pasting into support threads.
KWin version: 5.14.4
Qt Version: 5.12.0
Qt compile version: 5.11.2
XCB compile version: 1.13.1
Operation Mode: X11 only
Vendor Release: 12003000
Protocol Version/Revision: 11/0
SHAPE: yes; Version: 0x11
RANDR: yes; Version: 0x14
DAMAGE: yes; Version: 0x11
Composite: yes; Version: 0x4
RENDER: yes; Version: 0xb
XFIXES: yes; Version: 0x50
SYNC: yes; Version: 0x31
GLX: yes; Version: 0x0
decorationButtonsLeft: 0, 2
decorationButtonsRight: 6, 3, 4, 5
font: Noto Sans,10,-1,5,50,0,0,0,0,0
Active screen follows mouse: no
Number of Screens: 1
Refresh Rate: 60
Compositing is active
Compositing Type: OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Desktop
OpenGL version string: 4.5 (Core Profile) Mesa 18.3.1
OpenGL platform interface: GLX
OpenGL shading language version string: 4.50
GPU class: Haswell
OpenGL version: 4.5
GLSL version: 4.50
Mesa version: 18.3.1
Linux kernel version: 4.20
Direct rendering: Requires strict binding: yes
GLSL shaders: yes
Texture NPOT support: yes
Virtual Machine: no
OpenGL 2 Shaders are used
Painting blocks for vertical retrace: no
Currently Active Effects:
Created attachment 147880 [details]
Minimal Qt5 program to dump QScreen information
Nothing in this output shows any problem I can identify :-(
I've added a minimal program to dump all QScreen information. It's just a 64bit binary, but I included the source if you need to build a 32bit version. This can be done simply by calling
$ qmake && make
Please run it on the same screen from a terminal, where you start LO.
For my single NEC monitor the output is:
availableGeometry: QRect(0,0 1920x1170)
availableSize: QSize(1920, 1170)
availableVirtualGeometry: QRect(0,0 1920x1170)
availableVirtualSize: QSize(1920, 1170)
geometry: QRect(0,0 1920x1200)
physicalSize: QSizeF(518, 324)
size: QSize(1920, 1200)
virtualGeometry: QRect(0,0 1920x1200)
virtualSiblings: (QScreen(0x563f582e6780, name="DVI-0"))
virtualSize: QSize(1920, 1200)
The interesting part is probably physicalSize (and the resulting physicalDotsPerInch). Those numbers look off... (but KDE and other Qt applications look perfect).
manufacturer: "Samsung Electric Company"
availableGeometry: QRect(0,0 1920x1026)
availableSize: QSize(1920, 1026)
availableVirtualGeometry: QRect(0,0 1920x1026)
availableVirtualSize: QSize(1920, 1026)
geometry: QRect(0,0 1920x1080)
physicalSize: QSizeF(160, 90)
size: QSize(1920, 1080)
virtualGeometry: QRect(0,0 1920x1080)
virtualSiblings: (QScreen(0x55aff8c7a610, name="HDMI-2"))
virtualSize: QSize(1920, 1080)
(In reply to Bernhard Rosenkraenzer from comment #6)
> The interesting part is probably physicalSize (and the resulting
> physicalDotsPerInch). Those numbers look off... (but KDE and other Qt
> applications look perfect).
> logicalDotsPerInch: 96
> physicalDotsPerInch: 304.8
> physicalSize: QSizeF(160, 90)
Yup - that would be a tiny screen, as it's in mm...
xdpyinfo seems more correct with "508x317 millimeters"; not sure if this is a guess based on the 96 DPI or on real data.
The icons are roughly scaled 3x when I tried to measure their rectangle using gimp, so that would correspond to logicalDotsPerInch : physicalDotsPerInch.
Currently Qt5Font uses QFont::setPixelSize to set the font size. Quoting the docs: "Using this function makes the font device dependent. Use setPointSize() or setPointSizeF() to set the size of the font in a device independent manner."
So in theory
+ setPointSizeF(rFSP.mfExactHeight * 72.0 / QGuiApplication::primaryScreen()->logicalDotsPerInch());
should fix your problem. Docs for QScreen::logicalDotsPerInch claim "this value can be used to convert font point sizes to pixel sizes".
My final patch is a bit different. LO still looks ok for me, but I have no idea, if this would work for you.
Maybe this needs adaption of Qt5Font::ImplGetGlyphBoundRect too
Can you test the patch at https://gerrit.libreoffice.org/#/c/65696/ ?
Still looks the same after applying the patch (and updating to 220.127.116.11)
New patch, which might be related: https://gerrit.libreoffice.org/#/c/66525/
(In reply to Jan-Marek Glogowski from comment #9)
> New patch, which might be related: https://gerrit.libreoffice.org/#/c/66525/
@Bernhard: The patch was merged to master now. Any chance you could do a quick test whether this fixes the issue for you?
Setting to NEEDINFO until the question from comment:10 has been answered.
(In reply to Michael Weghorn from comment #10)
> (In reply to Jan-Marek Glogowski from comment #9)
> > New patch, which might be related: https://gerrit.libreoffice.org/#/c/66525/
> @Bernhard: The patch was merged to master now. Any chance you could do a
> quick test whether this fixes the issue for you?
Since a potential fix has been merged and there has been no reply in the meantime, let's set this to WORKSFORME.
@Bernhard: Please just reopen this bug if the problem is still there for you with a current master build.