Bug 92375 - Impress loses cropped image ratio on saving and re-opening in different LO versions.
Summary: Impress loses cropped image ratio on saving and re-opening in different LO ve...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
4.0.4.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Image-Crop Image-DPI
  Show dependency treegraph
 
Reported: 2015-06-27 10:06 UTC by Pascal Hingamp
Modified: 2020-05-11 12:02 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
.odp file which shows in slide 2 a deformed image. Slide 1 is ok. (757.30 KB, application/vnd.oasis.opendocument.presentation)
2015-06-27 10:06 UTC, Pascal Hingamp
Details
What the slides looked like on production on PC1 (455.48 KB, application/pdf)
2015-06-27 10:08 UTC, Pascal Hingamp
Details
How the slides look on opening on PC2 (compare slide 2 with slide 2 in other PDF) (466.93 KB, application/pdf)
2015-06-27 10:09 UTC, Pascal Hingamp
Details
A single slide example showing original rendering in version A of LO (206.88 KB, image/png)
2015-06-29 08:03 UTC, Pascal Hingamp
Details
A single slide example showing mangled rendering in version B of LO (141.91 KB, image/png)
2015-06-29 08:07 UTC, Pascal Hingamp
Details
screencast of removing user profile and opening the .odp file in LO 4.4.3.2 (4.68 MB, video/ogg)
2015-06-30 01:47 UTC, Pascal Hingamp
Details
screencast of removing user profile and opening the .odp file in LO 4.4.2.2 (5.97 MB, video/ogg)
2015-06-30 02:29 UTC, Pascal Hingamp
Details
Deformed Slides on Mac OS X with LibreOffice 5.1.0.3 (635.29 KB, image/png)
2016-03-19 18:09 UTC, gat
Details
Deformed Slides on Mac OS X with LibreOffice 5.1.1.3 (599.52 KB, image/png)
2016-03-19 18:46 UTC, gat
Details
Screenshots from Windows 10, using 100% and 150% scaling in screen settings (1.12 MB, application/pdf)
2019-10-21 09:57 UTC, Lars Jødal
Details
Screenshot of attachment 116864 opened under macOS at 118 dpi (649.65 KB, image/png)
2019-10-21 11:29 UTC, Andrew Watson
Details
Screenshot of attachment 116864 opened with LO 3.3 on macOS at 118 dpi (506.95 KB, image/png)
2019-10-21 14:14 UTC, Andrew Watson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pascal Hingamp 2015-06-27 10:06:28 UTC
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)
Comment 1 Pascal Hingamp 2015-06-27 10:08:10 UTC
Created attachment 116865 [details]
What the slides looked like on production on PC1
Comment 2 Pascal Hingamp 2015-06-27 10:09:19 UTC
Created attachment 116866 [details]
How the slides look on opening on PC2 (compare slide 2 with slide 2 in other PDF)
Comment 3 Pascal Hingamp 2015-06-29 08:00:42 UTC
(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...
Comment 4 Pascal Hingamp 2015-06-29 08:03:39 UTC
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!
Comment 5 Pascal Hingamp 2015-06-29 08:07:15 UTC
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:(
Comment 6 Buovjaga 2015-06-29 18:31:24 UTC
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
Comment 7 Pascal Hingamp 2015-06-30 01:46:25 UTC
(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!
Comment 8 Pascal Hingamp 2015-06-30 01:47:46 UTC
Created attachment 116938 [details]
screencast of removing user profile and opening the .odp file in LO 4.4.3.2
Comment 9 Pascal Hingamp 2015-06-30 02:12:16 UTC
(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.
Comment 10 Pascal Hingamp 2015-06-30 02:29:48 UTC
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
Comment 11 skiani 2015-07-03 13:54:05 UTC
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.
Comment 12 Buovjaga 2015-07-03 13:59:52 UTC
(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]?
Comment 13 Pascal Hingamp 2015-07-03 14:10:19 UTC
(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.
Comment 14 Pascal Hingamp 2015-07-03 14:13:53 UTC
(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.
Comment 15 Pascal Hingamp 2015-07-03 18:03:12 UTC
(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.
Comment 16 gat 2016-03-19 17:16:29 UTC
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.
Comment 17 gat 2016-03-19 18:09:37 UTC
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).
Comment 18 gat 2016-03-19 18:10:37 UTC
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.
Comment 19 gat 2016-03-19 18:46:50 UTC
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.
Comment 20 gat 2016-03-19 19:00:57 UTC
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.
Comment 21 gat 2016-03-19 19:21:34 UTC
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.
Comment 22 Christian Assig 2016-04-27 17:16:46 UTC
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.
Comment 23 Christian Assig 2016-04-27 18:09:58 UTC
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?
Comment 24 Buovjaga 2016-04-28 05:32:10 UTC
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.
Comment 25 Christian Assig 2016-04-29 07:57:56 UTC
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.
Comment 26 Christian Assig 2016-05-05 13:26:02 UTC
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.
Comment 27 Pascal Hingamp 2016-06-14 08:52:02 UTC
(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.
Comment 28 QA Administrators 2019-06-25 02:42:53 UTC Comment hidden (obsolete)
Comment 29 Lars Jødal 2019-10-21 08:17:27 UTC
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
Comment 30 Horst Schirmeier 2019-10-21 09:06:57 UTC
(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.
Comment 31 Lars Jødal 2019-10-21 09:57:57 UTC
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.
Comment 32 Andrew Watson 2019-10-21 11:29:32 UTC
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
Comment 33 Lars Jødal 2019-10-21 12:39:42 UTC
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)
Comment 34 Andrew Watson 2019-10-21 14:14:31 UTC
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.
Comment 35 Andrew Watson 2020-05-11 12:02:56 UTC
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].