Bug 112538 - Cropped image created by MAC Impress cannot display correctly in the Windows Impress
Summary: Cropped image created by MAC Impress cannot display correctly in the Windows ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
5.4.1.2 release
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 116131 (view as bug list)
Depends on:
Blocks: Image-DPI
  Show dependency treegraph
 
Reported: 2017-09-21 01:55 UTC by weichen.chu
Modified: 2019-08-19 06:56 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Test Crop function in MAC and Windows Impress (537.36 KB, application/vnd.oasis.opendocument.presentation)
2017-09-21 09:34 UTC, weichen.chu
Details
Sample file (395.72 KB, application/vnd.oasis.opendocument.presentation)
2018-02-28 15:15 UTC, Telesto
Details
Screenshot Windows (96DPI screen) (121.10 KB, image/jpeg)
2018-02-28 15:15 UTC, Telesto
Details
Screenshot Mac (probably 135dpi) (321.29 KB, image/png)
2018-02-28 15:17 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description weichen.chu 2017-09-21 01:55:02 UTC
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
Comment 1 Alex Thurgood 2017-09-21 08:17:22 UTC
@welchen : please provide us with a sample Impress document containing a cropped image created on Mac with which we can test.
Comment 2 weichen.chu 2017-09-21 09:34:33 UTC
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)
Comment 3 Alex Thurgood 2017-09-21 14:57:31 UTC
Thanks, will test and report back.
Comment 4 weichen.chu 2017-09-22 05:40:19 UTC
Sorry, the third slide was cropped by the windows impress.
Comment 5 Alex Thurgood 2017-09-22 09:28:32 UTC
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 ?
Comment 6 weichen.chu 2017-09-23 22:51:44 UTC
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.
Comment 7 Alex Thurgood 2017-10-13 10:48:40 UTC
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).
Comment 8 tryagain 2018-01-05 22:15:25 UTC
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.
Comment 9 tryagain 2018-01-07 22:23:32 UTC
(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...
Comment 10 Tor Lillqvist 2018-02-27 10:59:23 UTC
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.)
Comment 11 Tor Lillqvist 2018-02-28 13:34:17 UTC
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.
Comment 12 Telesto 2018-02-28 15:15:08 UTC
Created attachment 140222 [details]
Sample file
Comment 13 Telesto 2018-02-28 15:15:49 UTC
Created attachment 140223 [details]
Screenshot Windows (96DPI screen)
Comment 14 Telesto 2018-02-28 15:17:21 UTC
Created attachment 140224 [details]
Screenshot Mac (probably 135dpi)
Comment 15 Telesto 2018-02-28 15:28:18 UTC
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 ()
Comment 16 Tor Lillqvist 2018-02-28 17:41:53 UTC
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.
Comment 17 Telesto 2018-02-28 18:51:39 UTC
(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)
Comment 18 Chris Sherlock 2018-03-03 22:58:03 UTC Comment hidden (off-topic)
Comment 19 Aron Budea 2018-03-04 11:46:19 UTC
Is bug 116164 a duplicate of this?
Comment 20 Tor Lillqvist 2018-03-05 07:56:33 UTC
Aron, probably a different place in the code where the same mistake is made, I would keep it separate.
Comment 21 Aron Budea 2018-03-05 08:02:56 UTC
Okay, let's add it to the see also list, maybe once one is fixed, the same idea can be reused for the other.
Comment 22 Alex Thurgood 2018-03-06 08:42:40 UTC
*** Bug 116131 has been marked as a duplicate of this bug. ***
Comment 23 Tor Lillqvist 2018-05-22 12:52:00 UTC
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"?
Comment 24 Tor Lillqvist 2018-05-22 12:58:54 UTC
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.
Comment 25 Sven-Jacobi 2018-08-08 11:40:55 UTC
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
Comment 26 QA Administrators 2019-08-19 06:56:08 UTC
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