In some cases (seems to require a large PNG that gets resized and cropped in Impress), an embedded PNG in an Impress presentation gets distorted / stretched when the presentation is opened on a machine with a different font DPI setting, which is common for HiDPI setups.
Steps to Reproduce:
1. Embed a (large?) PNG in a presentation; resize + crop it. Example presentation attached.
2. Open the presentation in an X11 session with modified font DPI settings (e.g. KDE/Plasma: System settings -> Appearance -> Fonts -> Fonts -> Force fonts DPI = 192; or put "Xft.dpi = 192" in ~/.Xresources).
The embedded PNG does not look as when the presentation was created, but is horizontally stretched. The higher the DPI setting, the more the image is stretched.
Same look / scaling / stretching / ... as when the presentation was created.
User Profile Reset: Yes
This bug was definitely already present in the 5.x releases, quite possibly earlier.
Created attachment 142990 [details]
Reproducing Impress presentation
Created attachment 142991 [details]
expected behavior (DPI same as when file was created)
Created attachment 142992 [details]
distortion with forced fonts DPI = 120
Created attachment 142993 [details]
distortion with forced fonts DPI = 140
Created attachment 142994 [details]
distortion with forced fonts DPI = 192 (only white part of image visible)
Note that this issue does not need KDE for reproduction. We also reproduced it e.g. on dwm with the aforementioned setting in ~/.Xresources.
Possibly a duplicate of #112538.
I think, that the behavior is correct, but unexpected for users:
The reason of the problem is, that the image itself has no information about dpi. And therefore this happens:
Because of the missing dpi information in the image, the dpi of the actual OS is used. The image has 1920 pixel width and 1080 pixel height. For me on a 120dpi system that results in 16inch width and 9inch height, that is 40.64 cm width and 22.86cm height. The crop value is absolute 23.35cm from right (fo:clip in file format). That results is an image of 17.29cm width and 22.86cm height. The frame, which holds the image, has absolute width 5.902cm and height 6.122cm. The image is fit to this frame size, which results in a scaling of 34.14% horizontal and 27.78% vertically.
To see the crop, scale and size values of the image, select the image and then use Format > Image > Crop Dialog. To see the frame size use Position&Size Dialog (key F4).
The unit px is excluded for clipping in file format, so there is no chance to set the clipping in percent of the pixel size of the image.
You can avoid such problems, if you explicitly set the dpi-value in the image. Then LibreOffice honors this value and the image has the same size in cm on all systems.
(In reply to Regina Henschel from comment #8)
> I think, that the behavior is correct, but unexpected for users:
> The reason of the problem is, that the image itself has no information about
> dpi. And therefore this happens: [...]
> You can avoid such problems, if you explicitly set the dpi-value in the
> image. Then LibreOffice honors this value and the image has the same size in
> cm on all systems.
I don't think many people would agree with you that it's "correct" for a presentation program to save a presentation in a way that's not portable.
Of course, your image DPI / environment DPI discussion perfectly explains the technical reason this happens (just as the bug report I referred to earlier does), but that doesn't make it "correct" from a user's perspective. I'd still call a bug a bug (which should be solved by e.g. additionally storing the DPI value that was assumed when importing / cropping the image in the presentation file), and not blame it on the user for not manually specifying an arbitrary DPI value for an imported image file.
In fact, I think this is a particularly nasty, user-experience shattering bug, as it can blow up in a presenter's face right when doing the actual presentation -- on a presentation notebook provided by a conference / meeting host -- when the .odp looked perfect up until the very last moment they copied it onto an USB stick.
Dear Horst Schirmeier,
A new major release of LibreOffice is available since this bug was reported.
Could you please try to reproduce it with the latest version of LibreOffice
from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' if the bug is still present in the latest version.
Still reproducible with LO 220.127.116.11 (creating a new document using that version and DPI = 128, reopening it in a DPI = 192 environment).
Still reproducible with LO 18.104.22.168.
I can confirm this bug on Windows 10, when screen scaling is changed. Thus, the bug is not limited to Linux and X11.
Steps to change screen scaling in Windows 10:
1. Right-click on Windows background
2. Choose "Screen settings"
3. Change scaling from 100% to e.g. 150%
4. Do a logout and re-login, even if Windows itself changes appearance immediately.
With the new scaling, the image is enlarged but still have the same borders. For this reason, part of the image is lost (right part and bottom part) - rather similar to what is shown in attachment 142993 [details].
I agree with Horst Schirmeier that the technical details should be the responsibility of Impress, not of the user, i.e. this is a bug, not a feature.
Status changed to NEW, operating system to All.
(The bug title should probably be changed too, but I will leave that to the original reporter to avoid "hiding" the bug from being found.)
Version: 22.214.171.124 (x64)
Build ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win;
Locale: da-DK (da_DK); UI-Language: en-GB
Testing on Windows 10 with 150% scaling (see my comment 13) in various old versions, I find that the bug appears to be introduced in version 4.0.4:
LO 126.96.36.199 (and earlier versions): The image is shown correctly.
LO 188.8.131.52 (and later versions): The image is incorrectly scaled up and cut.
(Similar findings for bug 92375 - these bugs appear to be expressions of the same underlying problem)
We have seen same type of bug (with image imported or just with text zone) between Impress 184.108.40.206 (where we have create file) and Impress 220.127.116.11 (both on Debian).
We have also some problem on Windows7 with Impress 18.104.22.168
We don't really unerstand what is going on because size of picture is the same in properties.
Bug just exist from 5.x to 6.x (in all 6.x bug is the same).