Comment # 21 on bug 1123424 from Fabian Vogt

(In reply to Stefan Hundhammer from comment #19)
> tux@g1:~> xrdb -query | grep Xft
> Xft.dpi:	120.9599609375

This seems to be the culprit to me.
Does it work after running "echo Xft.dpi: 120 | xrdb -nocpp -merge"?

If that's not enough, does
"QT_LOGGING_RULES=qt.qpa.screen.debug=true QT_FONT_DPI=120 qdirstat" work?

> Xft.antialias:	1
> Xft.hinting:	1
> Xft.hintstyle:	hintslight
> Xft.rgba:	none
> 
> tux@g1:~> QT_LOGGING_RULES=qt.qpa.screen.debug=true qdirstat .
> Logging to /tmp/qdirstat-tux/qdirstat.log
> 
> tux@g1:~> fgrep '<Verbose>' /tmp/qdirstat-tux/qdirstat.log 
> 2019-03-04 17:36:58.204 [2558] <Verbose> Failed to parse EDID data for
> output "XWAYLAND0" edid data:  ""
> 
> 2019-03-04 17:36:58.208 [2558] <Verbose> adding QXcbScreen(0x5596f81fc8b0,
> name="XWAYLAND0", geometry=1680x1050+0+0, availableGeometry=1680x1016+0+34,
> devicePixelRatio=1.0, logicalDpi=QPair(inf,inf), physicalSize=0.0x0.0mm,
                                         ^^^^^^^

That doesn't look right either, but it might be unrelated. It's caused by the
invalid physicalSize value, so the safeguards there didn't work for some
reason.
I'll have a look at that tomorrow. What does xrandr show as geometry?

> screenNumber=0, virtualSize=1680x1050 (1680.0x1050.0mm),
> orientation=Qt::LandscapeOrientation, depth=24, refreshRate=59.0, root=38c,
> windowManagerName="GNOME Shell") (Primary: true )
> 
> 2019-03-04 17:36:58.208 [2558] <Verbose> primary output is "XWAYLAND0"