Description: Cropping of images in impress appears to be broken to the point of being unusable on Linux. Today, displaying a presentation, I noticed all the cropped images I had were displayed with wrong cropping. This felt strange to me, because I had just tried the presentation on another computer with a very similar setup and everything was OK. So I started looking into the matter: - Same odp file - Two computers with recent linux versions with KDE (one with Manjaro Linux, the other with Kubuntu) - Quite similar LibO versions (7.5.0.3 on manjaro from the distro, 7.5.1.2 on kubuntu from TDF) Correct display on one machine (manjaro), wrong on the other one (kubuntu). So I started looking at what could be different across the two systems and I found this notable discrepancy: If you select the cropped image and you go to Format->Image->Crop Dialog, the crop dialog window that appears shows various pieces of information about the cropped image. Specifically, left of the "original size" button, you get some info about the image size. The latter is shown both in pixels and in mm. Furthermore the resolution in DPI is given. Now, while the size in pixel was the same on the two systems, the size in mm and the DPI were different! Interestingly, one of the system was showing 96 dpi and the other one 110. The latter number resonated with me. So I went on the desktop environment setting and I checked. In the "fonts" panel there is a "Force fonts DPI" entry meant to tell X about the screen DPI to scale the fonts accordingly. On one system this value was at the default (96), while on the other one (the one mis-displaying the cropped image) it was at (110). Bingo! Changing the "Force fonts DPI" setting on KDE affects the image resolution that LibO uses for image cropping. Putting the value down to 96 on the system that was mis-displaying the cropped images magically made them correct! Obviously to have cropping dependent on a setting made for the DE font scaling makes no sense. Tested LibO 7.4.x and it has the same issue. Steps to Reproduce: See the description above Actual Results: See the description above Expected Results: See the description above Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: PresentationDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes
Incidentally, the DPI shown in the "crop" dialog is different from the one shown in the "compress" dialog that is correct.
Tibor, this might be a long short but could this report be related to bug 154905 ? I could not reproduce using GNOME's "Large text" accessibility feature, nor changing the screen scaling, but someone needs to test with KDE.
Forgot to mention that on both machines I am on X11, not Wayland. I think that the resolution you set with KDE's Force font DPI option goes in the XResources database as `Xft.dpi`. Not sure it also goes elsewhere, but certainly you can query it back from `xrdb`. I think that XResources named `Xft.*` represent a configuration mechanism predating fontconfig and different from a global screen scaling or accessibility features. Maybe it has been dropped from the Gnome settings UI. However, you should still be able to configure it with `xrdb`. Now I wonder if there may be parts of LibO code that were coded back when XResources where the main configuration means and if the value of the `Xft.dpi` setting is read from there and possibly used incorrectly in some newer code.
I found this is the exact same issue described by OP in bug 118299 (see attachment 142990 [details]), so marking as duplicate. Thank you! *** This bug has been marked as a duplicate of bug 118299 ***