Using the command:

libreoffice7.4 --convert-to ods original.xlsx

(But it's the same result as using File > Save as... > ODS, then File > Reload.)

I can see the following elements moved down:

- The top embedded spreadsheet
- The bottom linked spreadsheet
- The top-right embedded image object

Tested with:

Version: 7.4.5.1 / LibreOffice Community
Build ID: 9c0871452b3918c1019dde9bfac75448afc4b57f
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

Same with slight differences in a recent master build:

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 69c6f7bccec838b7288a25a29a83b7f782ba7586
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

But in general, the (parts of) elements moving down / losing their Y axis location when opening the ODS is a regression, as I can reproduce in:

Version: 6.2.0.0.beta1
Build ID: d1b41307be3f8c19fe6f1938cf056e7ff1eb1d18
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3; 
Locale: en-AU (en_AU.UTF-8); UI-Language: en-US
Calc: threaded

But not in:

Version: 6.1.0.3
Build ID: efb621ed25068d70781dc026f7e9c5187a4decd1
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk2; 
Locale: en-AU (en_AU.UTF-8); Calc: group threaded

This is regardless of what version was used to convert the file, which makes me think its a FILEOPEN issue with ODS.

assk, which part is an EMF? All I can see is PNG and JPG. (The 3D model comes across as a picture.)

Note that MS Excel opens the ODS file with the elements at the correct Y position!

Microsoft 365 MSO (Version 2212 Build 16.0.15928.20196) 64-bit

When you embed another OOXML package in an OOXML spreadsheet i.e. XLSX using Excelm then Excel will both embed the package and generate a snapshot of the embedded data and save it as an .emf image file in the URI xl/media/

Formally, they are saved as relationships to a WorksheetPart as an ImagePart and to a VmlDrawingsPart.

So these images are not real embedded images by the user, but Excel generated images of an embedded package. They are great to keep, if you want to remove the embedded package but keep the image snapshot of the data.

You can find the image controls of these emfs in a file called vmlDrawing1.vml under xl/drawings

These images are represented in drawing1.xml and they do not have Blip image controls.

What I see is that the row height changes from 0,53 cm to 0,49 cm. I see no difference in this regard in 6.1 or 6.2 bibisect repos. Stéphane, can you give more details about this difference you see?

Created attachment 185036 [details]
test results with MS Excel and LO 7.6 alpha0+

Attached PDF shows three screenshots:
- Original XLSX displayed in MS Excel
- Original XLSX displayed in LO recent master build
- Saved as ODS and reloaded in LO recent master build

Versions:

Microsoft® Word for Microsoft 365 MSO (Version 2212 Build 16.0.15928.20196) 64-bit 

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: ec4babad021218b75dfe8534985d7db525edde69
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

I did a bibisect with linux-64-6.0, keeping an eye on the 1 2 3 dropping below the white rectangle with black borders. IMPORTANT: I checked by opening the .ods with 7.4. The file open result is different with older versions.

Result:
https://git.libreoffice.org/core/commit/286c27e805c4501451857abff19c23b3719146a3
tdf#111548: Better fix for PPTX / XLSX import of ActiveX controls

Tamás is no longer active, so I won't bother him with this.

Thanks, Ilmari. You're right, what I saw in 6.2 and described at the end of comment 1 was the impact of the famous row height recalculation commit 1e55a47e89a9d9d6cf9cb3993484022aaf2c097b. Sorry about the confusion.

Adding metas but you might be able to think of better ones.

Created attachment 189382 [details]
XLSX file on which the issue could be reproduced

Created attachment 189383 [details]
XLSX file resaved with LO 7.5.5

The issue is reproducible also after resaving it to XLSX with LibreOffice.

Any news on getting this fixed?