Created attachment 116864 [details] .odp file which shows in slide 2 a deformed image. Slide 1 is ok. I have a large 100+ slide presentation (145MB) with most slides containing images either inserted from Insert->Image" or pasted (CTRL-V) from the Clipboard (originating from screen shots copied into Clipboard using screenshot v3.10.1). Problem: ======== This presentation was produced on PC1 (LO 4.4). When opened on my PC2 laptop night before before my talk, ALL the images that had been cropped had their size ratio totally messed up. See an example of two such slides in the attached files (the first slide has un-cropped image which is not affected, the second slide has a cropped image which appears deformed on PC2): PDF version 1: what the slide looked like in LO on PC1. PDF version 2: what the slide looked like on opening in LO on PC2. File as produced on PC1 (which is garbled on opening in PC2) is also attached. Expected behavior: ================== When opening an .odp file, cropped images should be rendered exactly the same whatever the LO or OS version. PC N°1: OS: Ubuntu 15.04 RAM: 16GB CPU: to be confirmed if required LO: standard vivid version: 4.4.2-0ubuntu2? to be confirmed if required on monday PC N°2: OS: Ubuntu 14.10 RAM: 8GB CPU: 64bit Intel® Core™ i7-2720QM CPU @ 2.20GHz × 8 LO: Version: 4.3.7.2 Build ID: 430m0(Build:2)
Created attachment 116865 [details] What the slides looked like on production on PC1
Created attachment 116866 [details] How the slides look on opening on PC2 (compare slide 2 with slide 2 in other PDF)
(In reply to Pascal Hingamp from comment #0) Being back at work I can confirm that this cropped image mangling is bi-directional from two different versions of Impress: Actions to reproduce: ===================== open Impress document in LO Version: 4.3.7.2 Build ID: 430m0(Build:2) insert an image, crop, resize. save, close. re-open in LO Version: 4.4.2.2 Build ID: 40m0(Build:2) the cropped images are mangled (h x w ratio lost) The reverse is also true! Painfully repair the images in LO Version: 4.4.2.2 Build ID: 40m0(Build:2), save, close, re-open in LO Version: 4.3.7.2 Build ID: 430m0(Build:2) and the images are mangled again...
Created attachment 116904 [details] A single slide example showing original rendering in version A of LO Notice the importance of having the size ratios and crops precisely maintained because of the numerous image annotations!
Created attachment 116905 [details] A single slide example showing mangled rendering in version B of LO The overall dimensions of the image in the slide have been preserved, but the aspect ratio is all mangled. Making the annotations out of sync with image & therefore a whole painfully built 100+ slide presentation totally useless the night before the seminar:(
Slide 2 is OK for me on 4.3.7 (Linux) and 4.3.0 (Windows) Might it be due to corruption in the 4.3 version's user profile? https://wiki.documentfoundation.org/User_Profile#Resolving_corruption_in_the_user_profile Ubuntu 15.04 64-bit Version: 4.3.7.1 Build ID: f08731f5dacd79f6348052311f5b237b002d78da Win 7 Pro 64-bit Versio: 4.3.0.1 Käännöksen ID: 67f5430184326974072b65403ef1d9d934fc4481
(In reply to Beluga from comment #6) > Slide 2 is OK for me on 4.3.7 (Linux) and 4.3.0 (Windows) > > Might it be due to corruption in the 4.3 version's user profile? > https://wiki.documentfoundation.org/ > User_Profile#Resolving_corruption_in_the_user_profile I had already moved my LO profile out of the way on my laptop with 4.3.7.2 following a similar suggestion in another unrelated bug report I have filed. Just to demonstrate in case there are some doubts, I have made a screencast where I move my profile out of the way, then open the LO .odp document directly from the link above. It shows slide 2 mangled. I will now do the same screencast on my workstation with LO 4.4.2.2 to show images in the very same document are rendered completely differently!
Created attachment 116938 [details] screencast of removing user profile and opening the .odp file in LO 4.4.3.2
(In reply to Pascal Hingamp from comment #8) > directly from the link above. It shows slide 2 mangled. I will now do the > same screencast on my workstation with LO 4.4.2.2 to show images in the very > same document are rendered completely differently! I forgot to mention that following suggestions on another unrelated bug report I updated LO using the ubuntu ppa repo, so the version on my PC2 (laptop) is now 4.4.3.2. This suggests this bug is not confined to just one LO version.
Created attachment 116940 [details] screencast of removing user profile and opening the .odp file in LO 4.4.2.2 After removing the user LO profile, I open the very same document (from the bug report above) in LO 4.4.2.2 and you can see how the image on slide 2 is rendered differently compared to the other screencast from LO 4.4.3.2. May I insist on the severity of this bug, it is a show stopper for anyone working on more than one PC or in close teamwork (that's most professionals), using Impress to create large number of slides based around images. In fact in my own case, it is the motivation to abandon LO altogether after months of loosing too much time because of various crippling bugs: see "I can no longer afford the LibreOffice suite" https://plus.google.com/+PascalHingamp/posts/eUMbgdTjgZZ
Total show stopper. Image crop confusion and lost images are killer. Makes a complete embarrassing mess in front of the crowd, no excuse, should have been fixed long ago.
(In reply to skiani from comment #11) > Total show stopper. Image crop confusion and lost images are killer. Makes a > complete embarrassing mess in front of the crowd, no excuse, should have > been fixed long ago. Can you reproduce the problem with attachment 116864 [details]?
(In reply to skiani from comment #11) > Total show stopper. Image crop confusion and lost images are killer. Makes a > complete embarrassing mess in front of the crowd, no excuse, should have > been fixed long ago. In my punishment I was lucky: I could spend the night before my seminar redoing my slides:) Lotsa cursing believe me. But indeed had I not tested my .odp file before the next day's seminar, it would basically have meant seminar cancellation live before the audience gathered to listen to the invited speaker. Nightmare, it's never happened to me, and I've never seen that happen before to anyone. That would be a very serious blow to one's reputation in the field.
(In reply to Beluga from comment #12) > (In reply to skiani from comment #11) > > Total show stopper. Image crop confusion and lost images are killer. Makes a > > complete embarrassing mess in front of the crowd, no excuse, should have > > been fixed long ago. > > Can you reproduce the problem with attachment 116864 [details]? The attached document 116864 opens and renders slide 2 two correctly in LO Version: 4.4.2.2 Build ID: 40m0(Build:2). For the same test on my second PC, I will do that when I'm home later tonight in reach of the laptop.
(In reply to Pascal Hingamp from comment #14) > (In reply to Beluga from comment #12) > > (In reply to skiani from comment #11) > > > Total show stopper. Image crop confusion and lost images are killer. Makes a > > > complete embarrassing mess in front of the crowd, no excuse, should have > > > been fixed long ago. > > > > Can you reproduce the problem with attachment 116864 [details]? > > The attached document 116864 opens and renders slide 2 two correctly in LO > Version: 4.4.2.2 Build ID: 40m0(Build:2). For the same test on my second PC, > I will do that when I'm home later tonight in reach of the laptop. I confirm that on my second PC (laptop running LO Version: 4.4.3.2 Build ID: 40m0(Build:2)) the attachment 116864 [details] opens with scrambled rendering of slide 2. Thanks for looking into this.
I confirm that downloading the original attachment (116864) in LibreOffice 5.0.5.2-6.fc23 (x86_64) shows the image on the second side flush to the right border. On LibreOffice 5.1.0.3 on Mac OS X shows the image partially un-viewable because it extends further right than the border for the slide. These were direct openings after saving his attachment. In his attachment the second slide had the image shifted to the left and text approaching from the right border. In my experience it looked perfectly fine on F23 with 5.0.5.2, but in Mac OS X with 5.1.0.3 the second slide had the image shifted to the right, past the right border. Also, on Mac OS X with 5.1.0.3 the text in the middle of the second slide is slightly cropped. I cannot confirm on Windows XP Service Pack 2 with LibreOffice 4.3.0.4. It shows the text and image on the second slide perfectly fine as expected by the original reporter. This is a great reminder to export all final slideshows as PDF as either a back-up or the final copy for use. Just for giggles, Apache OpenOffice 4.1.0 on Windows XP Service Pack 2 shows the image and text as the original reporter expects the image and text to appear. Since I was only able to reproduce on one computer/O.S./Build, I downloaded and opened the file three times and the issue was 100% reproducible. I plan to test 4.4.3.2 on Windows Vista Service Pack 2 to confirm that the build is the issue or that the issue is Linux/Unix related solely.
Created attachment 123722 [details] Deformed Slides on Mac OS X with LibreOffice 5.1.0.3 This is the malformed image and image of text on slide two of the original attachment (116864) that was tested on a MacBook Pro with Mac OS X (El Capitan - 10.11.3) with LibreOffice 5.1.0.3 (Build ID: 5e3e00a007d9b3b6efb6797a8b8e57b51ab1f73).
I retested LibreOffice 4.4.3.2 on Windows XP Service Pack 2. I could not confirm the issue of slide two being distorted; therefore, this is likely an issue that doesn't effect Windows since this specific build was supposed to have the issue.
Created attachment 123724 [details] Deformed Slides on Mac OS X with LibreOffice 5.1.1.3 I am receiving the same results as the earlier version on Mac OS X. Maybe I am having a different issue than what the original reporter was having.
I have confirmed that I am having the same issue with the same attachment on Mac OS X with two versions of LibreOffice that is not resolved by a restart nor renaming the user profile.
I could not confirm this issue on 5.1.0.3 of LibreOffice on Windows XP Service Pack 2 like I had on Mac OS X with the same version. This may be 64 bit and/or linux, unix only.
My wife is also affected by this bug. Now she is using Windows 10, LibreOffice 5.1.1.3, both 64 bit. All the slides she created last year on the same computer (Windows 7, not sure about the version of LibreOffice) are unusable now.
I have tried "deformed_slides.odp" from this bug and my wife's slides from last year look on a few more machines I have access to. All looks good on: - Ubuntu 16.04 64 bit, LibreOffice 5.1.2-0ubuntu1 - A VirtualBox machine running Windows 10 64 bit with a fresh installations of LibreOffice 5.1.2.2 64 bit - A VirtualBox machine running Windows 10 64 bit with a fresh installations of LibreOffice 5.1.2.2 32 bit Not good: - LibreOffice 5.1.0.3 running on Mac OS X 10.11.4 shows wrong areas of cropped images. Any ideas what else I might check to find out what causes this bug?
Christian: this bug was reported against Linux, so if 5.1.2 looks good for you on Linux, either the bug is fixed or you are seeing a different bug. To confirm you are seeing a different bug, please test with 5.1.2 on OS X. If the problem remains, then it is a different bug. It would of course be cool to hear Pascal's experience on Linux with 5.1.2 as well.
I think I have found out the reason for the problems described in this bug. After running some more tests on multiple computers, I noticed that the slides are shown correctly when the OS screen settings are set to 96 dpi, whereas the slides are distorted if the screen is set to some other dpi value. I changed the dpi setting on my wife's Windows 10 from 125% (120 dpi) to 100% (96 dpi). Afterwards (I needed to log off and log on on Windows 10), both "deformed_slides.odp" as well as her old files were shown correctly. http://www.tenforums.com/attachments/tutorials/50005d1448229663-dpi-scaling-level-displays-change-windows-10-a-dpi_in_settings-1.png Buovjaga, I believe this is the same bug Pascal experienced. In Comment 15, he wrote that one of his computers showed the slides correctly, while the other did not, using (almost?) the same version of LibreOffice, both on Linux. Pascal, should you read this, could you please run the following command on both of your computers (one that is affected by this bug and one that is not): xdpyinfo | grep -A3 ^screen The image 10000000000002D4000003D4D71AD281.png from deformed_slides.odp is a PNG without pHYs (Physical pixel dimensions). Thus, I assume that LibreOffice just uses the OS dpi setting to determine the original size of the image. The problem does not seem to be specific to a currrent version. In addition to LibreOffice 5.1.1, I have tried the following versions on Windows 10 with 120 dpi: LibreOfficePortablePrevious_4.2.8_MultilingualAll.paf LibreOfficePortablePrevious_4.4.7_MultilingualStandard.paf LibreOfficePortablePrevious_5.0.5_MultilingualStandard.paf In the crop dialog, I saw the following information, on any version, with any OS, with any dpi setting: Crop: Left: 0, Top: 0,53 cm, Right: 8,91 cm, Bottom: 0 Image size: Width: 6,84 cm, Height: 17,06 cm The following numbers differ: With 120 dpi: Original size: 15,32 cm x 20,74 cm, 120 PPI Scale: Width: 107%, Height: 84% With 96 dpi: Original size: 19,16 cm x 25,93 cm Scale: Width: 67%, Height: 67% By the way, I did not find a crop dialog with the numbers above in LibreOffice 5.1.x, only the drag and drop way to crop images. Is the crop dialog not available any more? Or can someone explain how I can open it? Like gat in Comment #16, I have also noticed that Apache OpenOffice (OpenOfficePortable_4.1.2_MultilingualStandard.paf) does not have the problem. With the OS set to either 96 or 120 dpi, it always shows the slides the same way, i.e. in the way that Pascal and I would consider the right way.
I could imagine that one of the two following approaches might help to solve this problem: a) Whenever a user adds an image to a presentation that does not contain pHYs, let LibreOffice add pHYs automatically. I would suggest the current dpi setting of the running OS. This way, the result (how the slides look) would still be the same as before on the original computer. And it would fix the problem that the slides look different after changing the dpi setting or when opening the file on a different computer with different dpi settings. A drawback of this approach would be that files created earlier (with images without pHYs) would continue to be affected by this problem. b) Do it like Apache OpenOffice. From what I have seen, current OpenOpffice versions (4.1.2) seem to use 96 dpi as the default value if the file does not include pHYs. Or does it use some kind of metadata stored elsewhere? This would help me and the original bug reporter to get the expected results (the files were created on computers with 96 dpi, and we have problems with computers set to 120 dpi). Of course, there is a major drawback to this approach as well: All users who created files with the OS set to 120 dpi will get distorted slides on the same computer, only by upgrading LibreOffice, without touching their dpi settings. Any other ideas how this problem could be solved? Personally, I would prefer approach a), as it solves the problem for files created with future versions containing the fix, and it does not create problems with files created in the past for users who only upgrade LibreOffice, but do not change their dpi settings.
(In reply to Buovjaga from comment #24) > Christian: this bug was reported against Linux, so if 5.1.2 looks good for > you on Linux, either the bug is fixed or you are seeing a different bug. > To confirm you are seeing a different bug, please test with 5.1.2 on OS X. > If the problem remains, then it is a different bug. > > It would of course be cool to hear Pascal's experience on Linux with 5.1.2 > as well. Hi, sorry I've been following but not had time to respond. I've checked and the slide 2 is still mangled on Linux with LO Version: 5.1.3.2 Build ID: 1:5.1.3-0ubuntu1 Threads CPU : 4; Version of OS :Linux 4.4; UI Render : default; It seems this bug is confirmed and the cause identified, I'm crossing fingers that a fix might be possible.
Dear Pascal Hingamp, 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Comment 25 suggests that the problem is related to screen settings being different on the two machines. Using LO 6.3.2.2 on Windows 10 with double screen, I have tested attachment 116864 [details] with various screen settings (1920x1080 down to 800x600, involving differences in both resolution and aspect ratio) and with different settings for scaling (standard 100% up to 175%). In this version of Windows, I find no mention of the dpi, but according to this link, https://www.tenforums.com/tutorials/5990-change-dpi-scaling-level-displays-windows-10-a.html, changing the scaling from 100% corresponds to changing the dpi. In all the configurations tested, both slides appeared correctly. Thus, the bug may have been solved since its reporting. 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
(In reply to Lars Jødal from comment #29) > In all the configurations tested, both slides appeared correctly. Thus, the > bug may have been solved since its reporting. I'm the reporter of duplicate bug #118299, and cannot confirm this bug being gone in LO 6.3.2.2. Still reproducible on Ubuntu 19.04 with the latest LO packages from libreoffice.org.
Created attachment 155185 [details] Screenshots from Windows 10, using 100% and 150% scaling in screen settings Sorry, I have to retract comment 29: I can reproduce the bug in Windows 10 using LO 6.3.2.2 by changing screen scaling to e.g. 150% AND doing a logout and re-login for the new scaling to be noted by all programs (not just the operating system). The attachment shows screenshots of the original test file (attachment 116864 [details]) with 100% scaling (ok) and 150% scaling (not ok). As described in bug #118299, the issue can be related to presentation including an image format that does not have information about dpi. I agree with Horst Schirmeier that this should be the responsibility of Impress, not of the user. I.e., it is a bug, not a feature.
Created attachment 155188 [details] Screenshot of attachment 116864 [details] opened under macOS at 118 dpi I've also been badly bitten by this bug when editing one Impress presentation on a Mac laptop that, when travelling, is used stand-alone (display resolution 128 dpi), but when in the office is used docked with the clamshell closed and driving an external keyboard and monitor (display resolution 118 dpi). Cropped images in one Impress file get re-scaled between editing sessions on the same machine, same LO version, depending on whether the document is opened when the machine is docked, or when the machine is being used stand-alone. This is certainly a serious bug. BTW, I tested the original test file (attachment 116864 [details]) under: Version: 6.4.0.0.alpha1 Build ID: cc57df8f942f239d29cb575ea5a7cb01405db787 CPU threads: 4; OS: Mac OS X 10.11.6; UI render: default; VCL: osx; Locale: en-GB (en_GB.UTF-8); UI-Language: en-GB Calc: threaded ... and got the attached result. Note that both images on page 2 are enlarged, losing information to the right and the bottom, but to a different extent than in the screen shot in attachment 155185 [details]. The small window in front of the LO Impress window is running dpi.jar: https://github.com/UprootLabs/grinder/releases/download/v1.0.1/dpi.jar This is a small Java program that reports the screen DPI seen via the Java APIs - see the last answer in this Stackoverflow thread: https://stackoverflow.com/questions/2621439/how-to-get-screen-dpi-linux-mac-programatically
Testing on Windows 10 with 150% scaling (see my comment 31) 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 images is shown correctly. LO 4.0.4.1 (and later versions): The image is incorrectly scaled up and cut. (Similar findings for bug 118299 - these bugs appear to be expressions of the same underlying problem)
Created attachment 155198 [details] Screenshot of attachment 116864 [details] opened with LO 3.3 on macOS at 118 dpi I tried opening attachment 155185 [details] with LO 3.3.0.4 (OOO330m19 (Build:6)) running under MacOS 10.11, and both images on page 2 are still enlarged (see attachment). The results look identical to opening the same file with LO 6.4.0.0.alpha1 on the same machine, same 118 dpi display (see attachment 155188 [details]). So the LO 4.0.3 -> LO 4.0.4 transition may not have introduced the bug in Mac OS LibreOffice.
Tested the original test file (attachment 116864 [details]) under: Version: 7.0.0.0.alpha1 Build ID: 6a03b2a54143a9bc0c6d4c7f1... CPU threads: 4; OS: Mac OS X 10.11.6; UI render: default; VCL: osx; Locale: en-GB (en_GB.UTF-8); UI: en-GB Calc: threaded Bug is still present - results on the same 118 dpi display are again as shown in attachment 155188 [details].
The same problem exists with cropped graphics: https://bugs.documentfoundation.org/show_bug.cgi?id=84800 There in my last comment I wrote: "If now a graphic does not have dpi information saved LO is using the monitor resolution to calculate the original size of the graphic -> and this is wrong... 96DPI should be used in this case as it was the case in OO4.0." and this should be fixed somehow. Please take 96dpi for graphis that did not have anz dpi information.
Tested the original test file (attachment 116864 [details]) under: Version: 7.1.1.2 / LibreOffice Community Build ID: fe0b08f4af1bacafe4c7ecc87ce55bb426164676 CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx Locale: en-GB (en_GB.UTF-8); UI: en-GB Calc: threaded Bug is still present - results on the same 118 dpi display are again as shown in attachment 155188 [details].
I just re-tested related bug #118299 with LO 7.3.1.3 and figured that the issue is gone; from the described symptoms I'd bet this one is, too. Please re-test.
I'm sorry to say that re-testing the original test file (attachment 116864 [details]) under: Version: 7.3.1.3 / LibreOffice Community Build ID: a69ca51ded25f3eefd52d7bf9a5fad8c90b87951 CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx Locale: en-GB (en_GB.UTF-8); UI: en-GB Calc: threaded ... shows that the bug is still present - results on the same 118 dpi display are again as shown in attachment 155188 [details].
Created attachment 183910 [details] A simple ODP with two cropped PNGs The attachment is a minimal reproducer. It was created on a system with 96 PPI screen resolution; two PNGs were prepared for it, both 100x100 pixels, with identical vertical 10-pixel color stripes. One has resolution (96 PPI) in metadata (the one with horizontal grey stripe); the other does not have such information. The inserted images were cropped 7 mm from right. When opened on a 96 PPI screen (on Windows, that means 100% UI scaling), both stripes are identical (and a bit of second green vertical stripe is visible on the right of both); but with another UI scaling, the one without PPI metadata (the top one) would get a different scale, making its stripes wider, and not matching the bottom one.
Created attachment 186871 [details] Python script to fix odf files with missing resolution data Thank you Mike Kaganski for your minimal reproducer. It helped me write a python script that analyzes and "fixes" odp files containing png images without resolution data (see attached). The script was able to successfully fix the problems I previously had with cropped images in odf files. The script treats the odp file as a zip file and checks all files contained in the zip file. If it finds png files without resolution data, it adds resolution data and writes the resulting files to a new zip/odp file. Currently, the script assumes a resolution of 96 dpi. You would need to change that (in line 31 of the script) if your images have a different resolution.
This issue of cropped images in Libre Office (LO) impress looking different on different PCs (PC1 and PC2) still exists. PC1: 13 inch screen, 1920 x 1080 display resolution, scale 100%, LO version 6.4.7.2, OS Ubuntu 20.04 PC2: 14 inch screen, 1900 x 1200 display resolution, scale 150%, LO version 7.5.7.1, OS MS Windows 11 Additional Information: NOTE: On the PC2 when I change the scale to 100% (same setting as that on PC1), then the LO impress shows the cropped images correctly. Of course, it is not very convenient to keep changing the scale settings as all the icons on 14 inch screen look very small with the 100% scale setting. Is there a way the cropped images in LO impress can preserve their form across different display formats, like when converted to .pdf? I guess, the LO could somehow be made read the scale of a particular PC and then rescale automatically when opened with a different PC.
Regina: do you think there's an existing feature in ODF to store a necessary info here - e.g., resulting PPI, or a rectangle - say, prior to transformations?