Description: 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). Actual Results: 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. Expected Results: Same look / scaling / stretching / ... as when the presentation was created. Reproducible: Always User Profile Reset: Yes Additional Info: 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 6.2.3.2 (creating a new document using that version and DPI = 128, reopening it in a DPI = 192 environment).
Still reproducible with LO 6.3.2.2.
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: 6.3.2.2 (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 Calc: CL
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 4.0.3.3 (and earlier versions): The image is shown correctly. LO 4.0.4.1 (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 5.2.7.2 (where we have create file) and Impress 6.1.5.2 (both on Debian). We have also some problem on Windows7 with Impress 6.4.1.2 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).
Dear Horst Schirmeier, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still reproducible with LO 7.2.5.2, but this seems to be fixed in 7.3.1.3! Even my original "Reproducing Impress presentation" is shown correctly in 7.3.1.3. Nice!
Sorry to say, testing on Windows 10, I find the bug to be still present with LO 7.3.1.3 The testing was on the original file, attachment 142990 [details], with scaling changed from 100% to 150% as described in comment 13. Changing status back to REOPENED.
*** Bug 154170 has been marked as a duplicate of this bug. ***
setting back to "new" as "reopened" is only for bugs that were previously marked as "fixed" by a commit.
This is not happening just on X11, but also on Wayland. I had an old presentation that I recently reopened on a new laptop using Wayland. This new machine has a 3k display and uses fractional scaling at 150%. All cropped images where wrong: both distorted and cropped incorrectly. Once fixed the presentation, I got it back on the original machine, also Wayland, but full-HD with scaling at 100% and the cropped images again were all wrong: both distorted and cropped incorrectly. Looks like it is impossible to use cropping across machines with different display settings. If you make them look right on a machine, then they are wrong on the other. This bug substantially makes cropping a feature to avoid, because it cannot be used reliably. In doubt, one should always crop the image with an external editor, and use the pre-cropped image in LibO. This is a serious issue: cropping is a feature that one should be able to take for granted in any Office-like suite and has evidently been broken for a large amount of time. Furthermore, the issue sometime does not even need moving to a different machine or a different display setting to trigger. Exporting to PDF may end up distorting cropped image if done programmatically after having lauched LibO with the `--headless` option.
Still seen on 7.6.1.2.
*** Bug 157362 has been marked as a duplicate of this bug. ***
(In reply to Buovjaga from comment #23) > *** Bug 157362 has been marked as a duplicate of this bug. *** This one has a macro example.