Description: The cropped image in the ODP file created by MAC Impress, cannot display correctly in the Windows Impress. Note: 1. The ODP file created by Windows Impress is fine, even it opened by Mac Impress. 2. It works well if you save as DOCX! Steps to Reproduce: 1.Paste any image in the slide (Mac Impress) 2.Crop the image and save the slides as ODP file. 3.Open the ODP file by Windows Impress Actual Results: Terrible image ratio and incorrect display of the cropped image can be observed. Expected Results: The files open by MAC or Windows Impress should have the same display of cropped images. Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36
@welchen : please provide us with a sample Impress document containing a cropped image created on Mac with which we can test.
Created attachment 136419 [details] Test Crop function in MAC and Windows Impress I found the cropped image created by MAC impress, could not display correctly in windows impress. And the cropped image created by Windows impress, could not display correctly in MAC impress. (This problem seems can be found in ODP format only)
Thanks, will test and report back.
Sorry, the third slide was cropped by the windows impress.
I probably won't be able to test this on a Win machine til next week, but I see the cropped 2nd slide in Impress for Mac (LO5412) and the stretched cropped 3rd slide that you cropped on Impress for Win. I am assuming that the 3rd slide made in Impress for Win did not have the stretched aspect ratio when you created it ?
To Alex: Yes, I did not stretched aspect ratio of the image in the third slide when I created it. The 3rd slide looks fine if you open by Windows Impress.
Confirming Tested on Version: 5.4.2.2 Build ID: 22b09f6418e8c2d508a9eaf86b2399209b0990f4 Threads CPU : 4; OS : Mac OS X 10.13; UI Render : par défaut; Locale : fr-FR (fr_FR.UTF-8); Calc: group and LibreOffice 5412 x64 Windows 10 The slides should indeed be displayed in the same way on each OS, but they are not: Slide 2 : the cropping in slide 2 is displayed differently on Mac and Windows (on Windows, the image is cropped more than on Mac Slide 3 : there is no cropping in the display of slide 3 on Windows, whereas the same slide is not only cropped, but also distorted (aspect ratio problem).
I think the problem is not related to Operating system used. It's most probably related to screen resolution of the system where the document was created and the one where it's being viewed. I hit a similar problem on a single computer running linux. To reproduce the problem, run Impress inside Xephyr nested X server with -dpi option value different to display resolution used at document creation time, and see all cropped images being broken. Restart Xephyr with the same -dpi as your desktop, and see the document is fine again. Same problem seems to exist in openoffice (and is reported to be present in staroffice too), see https://forum.openoffice.org/en/forum/viewtopic.php?f=10&t=73858 . Cropped images in my file have fo:clip attributes inside content.xml file. These attributes define cropped area by offsets expressed in centimetres. I guess, current display resolution at document creation time is used to convert pixels of actual image to centimetres. Then, at document display time, we probably have no information (or do not use it) about resolution used at document creation time, using instead current display resolution. So we get wrong part of image with a wrong scale. I think storing cropped area size in pixel units would be a fix.
(In reply to tryagain from comment #8) Sorry, I now unable to reproduce the problem as described in my earlier post. I now have a file which is broken with any resolution set, and a bunch of files which are good in this sense at any resolution. > To reproduce the problem, run Impress inside Xephyr nested X server with > -dpi option value different to display resolution used at document creation > time, and see all cropped images being broken. Restart Xephyr with the same > -dpi as your desktop, and see the document is fine again. > I think storing cropped area size in pixel units would be a fix. Sorry again, I have no such an easy solution now...
I think one can mostly ignore any details about how the attached document was created, which slide on what platform etc, and concentrate on the essential fact: That slide 2 looks significantly different in LibreOffice on macOS and on Windows. Both LibreOffice on Linux and Powerpoint 2013 on Windows also display it like LibreOffice on Windows. Thus I think we can be sure that it is LibreOffice on macOS that displays it wrong. (Even if the slide in question was created on a Mac, and while creating it, it of course looked as intended.)
Can anybody reproduce the problem from scratch using current master builds, BTW? I could not. If that indeed is the case now, that documents created newly in current LibreOffice versions don't exhibit this weird behaviour of cropped images, then the nature of this bug is somewhat different.
Created attachment 140222 [details] Sample file
Created attachment 140223 [details] Screenshot Windows (96DPI screen)
Created attachment 140224 [details] Screenshot Mac (probably 135dpi)
The DPI scaling setting seems to matter, based on bug 92375 comment 25 (didn't check). https://www.tenforums.com/tutorials/5990-change-dpi-scaling-level-displays-windows-10-a.html#option1 ()
Ha! Thanks for the link to bug #92375, that seems a bit more informative, and especially the "PNG without pHYs (Physical pixel dimensions)" probably is the key thing.
(In reply to Tor Lillqvist from comment #16) > Ha! Thanks for the link to bug #92375, that seems a bit more informative, > and especially the "PNG without pHYs (Physical pixel dimensions)" probably > is the key thing. Similar bugs can be found in meta bug 116082 (it isn't quite png specific)
Could it be an OLE object, per [MS-DOC] 2.6.1? “If the character is U+0001: - The operand of sprmCPicLocation is a position in the DataStream. If sprmCFData is also present and set to 1, the value specifies the position of a NilPICFAndBinData and describes binary data; otherwise the value specifies the position of a PICFAndOfficeArtData and describes a picture. If the character is U+0014: - If sprmCFOle2 is also present and set to "true" and the associated field does not have grffldEnd.fZombieEmbed set, the operand of sprmCPicLocation specifies the location of an OLE object storage. If the file is not encrypted with Office Binary Document RC4 CryptoAPI Encryption (section 2.2.6.3), the value specifies the name of an OLE object storage in the ObjectPool of the document.”
Is bug 116164 a duplicate of this?
Aron, probably a different place in the code where the same mistake is made, I would keep it separate.
Okay, let's add it to the see also list, maybe once one is fixed, the same idea can be reused for the other.
*** Bug 116131 has been marked as a duplicate of this bug. ***
I am almost tempted to say that whatever way one would try to fix this, it will cause a regression for somebody... Safer to just keep things as they are, and treat PNGs without pHYs as a case of "garbage in, garbage out"?
But yeah, one could introduce a new flag in new ODF documents created that would mean "in this document, PNGs without pHYs should be treated to be XX DPI, not whatever the user's monitor is", or something. Then existing documents would behave as before, and only newly created ones would be affected.
It is not only cropping that does not work the same happens with bitmap tilings. If the graphic itself does not contain dpi resolution then the application should use fixed 96dpi as it is done by the good old OpenOffice 4.0
Dear weichen.chu, 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
still repro in Version: 6.5.0.0.alpha0+ Build ID: e22a3f596ce50b5166063e217d96ef674a54d380 CPU threads: 4; OS: Mac OS X 10.15.2; UI render: GL; VCL: osx; Locale: ru-RU (ru_RU.UTF-8); UI-Language: en-US Calc: threaded
The same problem is still reproducible in version 6.3.3.2 However, if the ODP file opens by the google document, it displays correctly. If The ODP file converts into pptx file, and then opens in the LibreOffice, it displays correctly. In my impression, if the original file saved in the pptx, it works perfectly. Please consider this problem is a critical issue for the academic field.
Sorry, I found this problem also appears even you open the files in the google document or other platforms of LibreOffice. The best solution I found so far is to save as pptx format at the beginning. This bug will be a critical issue if you want to promote the ODF format.....
yes it is correct I had to try this on my website in my loptop
*** Bug 145319 has been marked as a duplicate of this bug. ***
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 using 7.3.1.3 on Windows 10 / Ubuntu 18.04 and can still reproduce this bug with the given test files: the crops are not identical in with these two OSes. I noticed with more agressive assymetric crops the images will get distorted even more.
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.