Bug 118299 - Impress distorts embedded PNG dep. on X11 font DPI setting
Summary: Impress distorts embedded PNG dep. on X11 font DPI setting
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
6.0.4.2 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevAdvice
Depends on:
Blocks: Image-DPI
  Show dependency treegraph
 
Reported: 2018-06-21 09:26 UTC by Horst Schirmeier
Modified: 2019-08-25 15:54 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Reproducing Impress presentation (1.22 MB, application/vnd.oasis.opendocument.presentation)
2018-06-21 09:28 UTC, Horst Schirmeier
Details
expected behavior (DPI same as when file was created) (338.39 KB, image/png)
2018-06-21 09:35 UTC, Horst Schirmeier
Details
distortion with forced fonts DPI = 120 (314.74 KB, image/png)
2018-06-21 09:36 UTC, Horst Schirmeier
Details
distortion with forced fonts DPI = 140 (277.96 KB, image/png)
2018-06-21 09:36 UTC, Horst Schirmeier
Details
distortion with forced fonts DPI = 192 (only white part of image visible) (218.05 KB, image/png)
2018-06-21 09:37 UTC, Horst Schirmeier
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Horst Schirmeier 2018-06-21 09:26:24 UTC
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.
Comment 1 Horst Schirmeier 2018-06-21 09:28:14 UTC
Created attachment 142990 [details]
Reproducing Impress presentation
Comment 2 Horst Schirmeier 2018-06-21 09:35:27 UTC
Created attachment 142991 [details]
expected behavior (DPI same as when file was created)
Comment 3 Horst Schirmeier 2018-06-21 09:36:08 UTC
Created attachment 142992 [details]
distortion with forced fonts DPI = 120
Comment 4 Horst Schirmeier 2018-06-21 09:36:37 UTC
Created attachment 142993 [details]
distortion with forced fonts DPI = 140
Comment 5 Horst Schirmeier 2018-06-21 09:37:14 UTC
Created attachment 142994 [details]
distortion with forced fonts DPI = 192 (only white part of image visible)
Comment 6 Horst Schirmeier 2018-06-21 09:38:24 UTC
Note that this issue does not need KDE for reproduction.  We also reproduced it e.g. on dwm with the aforementioned setting in ~/.Xresources.
Comment 7 Horst Schirmeier 2018-06-21 14:09:39 UTC
Possibly a duplicate of #112538.
Comment 8 Regina Henschel 2018-10-19 12:01:58 UTC
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.
Comment 9 Horst Schirmeier 2018-10-19 16:41:38 UTC
(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.
Comment 10 Xisco Faulí 2019-05-16 10:49:56 UTC
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.
Comment 11 Horst Schirmeier 2019-05-16 14:17:45 UTC
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).