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).