Bug 165127 - FILESAVE DOCX: round-trip completely fails to place images/table appropriately
Summary: FILESAVE DOCX: round-trip completely fails to place images/table appropriately
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
25.2.0.0 alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:25.8.0 target:25.2.0.2
Keywords: bibisected, bisected, filter:docx, regression
Depends on:
Blocks: DOCX
  Show dependency treegraph
 
Reported: 2025-02-08 14:11 UTC by Justin L
Modified: 2025-02-12 15:13 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
tdf109102-1.docx_export-compare-1.png: RED=25.2 master, BLUE=25.2 oldest, grayscale = Word 2019 (116.42 KB, image/png)
2025-02-08 14:11 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Justin L 2025-02-08 14:11:14 UTC
Created attachment 199071 [details]
tdf109102-1.docx_export-compare-1.png: RED=25.2 master, BLUE=25.2 oldest, grayscale = Word 2019

The position of the images has completely changed after a round-trip - seen both in MS Word and in Writer.

This started in 25.2 with commit c6f9d381d395a7573fc0c1eba4b73b0fdf50f047
Author: Xisco Fauli on Tue Oct 1 13:10:49 2024 +0200
    Add ODF 1.3 Extended / ODF 1.4 versions to configuration and UI

Since this is all DOCX, I doubt this is really a regression, but must have exposed something...

Steps to reproduce
1.) open Stagehandleiding 1718 v15062017.docx (attachment 134625 [details] from bug 109102)
2.) save and reload

It should look relatively identical to before. See attachment 134626 [details].

Found by Collabora's mso-test
Comment 1 mikhail.machine 2025-02-12 07:49:02 UTC
Hello Justin L,

I can't confirm that the bug is present in master.

Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: a8ec21adf255b70bb6eeb0a1717190df303d8b26
CPU threads: 12; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_FI); UI: en-US
Calc/Writer: threaded
Comment 2 Xisco Faulí 2025-02-12 08:59:12 UTC
Hi Justin,
I can't reproduce it in

Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 7da1497aa462e2b719aa9b308a749caf7b9a19b1
CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3
Locale: es-ES (es_ES.UTF-8); UI: en-US
Calc: threaded

Could you please try with a recent build ?
Comment 3 Xisco Faulí 2025-02-12 09:10:44 UTC
It seems the issue got fixed by

commit 61c12dd1c80e4b7227a614227bb690b00feb78ad	[log]
author	Mike Kaganski <mike.kaganski@collabora.com>	Tue Jan 07 13:30:18 2025 +0500
committer	Mike Kaganski <mike.kaganski@collabora.com>	Tue Jan 07 12:26:38 2025 +0100
tree 5ae0d1f0e17d5af9c3222faf6d7882327cfe3149
parent 242b8a9540f8e019dbe82c11d989d20d3a0f0ea7 [diff]

tdf#164619: bite the bullet, and write the correct ODF version

Closing
Comment 4 Justin L 2025-02-12 12:58:51 UTC
Oh good, Mike's patch was backported to 25.2.0.2.
Comment 5 Justin L 2025-02-12 14:05:09 UTC
I wanted to find out why an ODF version would have any impact on a DOCX import/export, but my debug build can't load this document without an assert.

But I did see things like
xmloff/source/style/HatchStyle.cxx:182: Check whether parameter isWrongOOo10thDegAngle can be false for newer LO version.

and LOTS of calls made to getODFVersionAny().

Anyway, thanks mike for fixing approximately everything in LO with that patch...
Comment 6 Xisco Faulí 2025-02-12 14:54:51 UTC
Hi Justin,
if you create a minimize sample I might write a unittest for it. Not sure I have much time for it at the moment...
Comment 7 Justin L 2025-02-12 15:13:33 UTC
(In reply to Xisco Faulí from comment #6)
> if you create a minimize sample I might write a unittest for it.
Nah. It is probably something extremely specific about this one document. This is the only document I found that had your name on it...