Bug 146383 - ODT->DOCX export: Wrap triggered around image after DOCX export
Summary: ODT->DOCX export: Wrap triggered around image after DOCX export
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.3.0.0 alpha1+
Hardware: All All
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, filter:docx, regression
Depends on:
Blocks: DOCX-Anchor-and-Text-Wrap
  Show dependency treegraph
 
Reported: 2021-12-23 09:28 UTC by Telesto
Modified: 2023-06-08 00:36 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Only Rectangle (26.71 KB, application/vnd.oasis.opendocument.text)
2021-12-30 20:04 UTC, Regina Henschel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2021-12-23 09:28:11 UTC
Description:
Wrap triggered around image after DOCX export

Steps to Reproduce:
1. Open attachment 164051 [details]
2. Save to DOCX
3. File reload

Actual Results:
An indent on the third line

Expected Results:
Same as ODT


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 6dbe55d34ad65627ef37f10dfdb548a717bb8c78
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 1 Telesto 2021-12-23 09:32:08 UTC
Still fine with
Version: 7.0.0.0.beta1+ (x64)
Build ID: 2891e91a513520d68ea2b8c59c14335861a15253
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 2 Telesto 2021-12-23 09:33:05 UTC
Still fine with
Version: 7.2.1.0.0+ (x64) / LibreOffice Community
Build ID: 8fdbb8aed1b48734a717d5f98ada566de7204605
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 3 Telesto 2021-12-23 09:34:30 UTC
Also in
Version: 7.3.0.0.alpha1+ (x64) / LibreOffice Community
Build ID: 7b0aabe71d2455f6f643553a07f1056935cf190f
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 4 Ezinne 2021-12-28 10:16:28 UTC
Reproducible in:

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 17a4f4d5e4d49189b43e748271d2d4fa330eef9b
CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 5 Kevin Suo 2021-12-29 01:54:48 UTC
Bibisected to:
$ git log --format=reference 253bee65bc24d999c3629a4d503d0fa01b355cfc..3262fc5ef3bde5b158909d11ccb008161ea95519
3262fc5ef3bd (tdf#142304 a.o. Improve wrap margins in docx filters, 2021-05-15)
2ffdd3706792 (tdf#139549 DOCX import: document got modified at import time, 2021-01-16)
67a56b715915 (sw: prefix members of HTMLTableColumn, HTMLTableContext, SwWriteTableCol ..., 2021-06-28)

Whereas the following one seems related:
commit 3262fc5ef3bde5b158909d11ccb008161ea95519
Author: Regina Henschel <rb.henschel@t-online.de>
Date:   Sat May 15 23:40:34 2021 +0200

    tdf#142304 a.o. Improve wrap margins in docx filters

Adding Regina Henschel to cc: would you please take a look? Thanks.
Comment 6 Regina Henschel 2021-12-29 21:04:31 UTC
The wrap is determined by a drawing object, which is a custom shape rectangle without fill and stroke. That is "Frame1" in the branch "Drawing objects" in Navigator.
This rectangle has a BoundRect, which is shifted up by 1 (Twips) compared with the FrameRect. You can see both with the "Development tools". There is a second object named "Frame1" in part "Shapes" in the "Object" pane in "Development tools". That is that from branch "Frames". That one from branch "Drawing objects" has "DYNAMIC" in the property "TextWrap".

Because the rectangle has no transformation and no stroke, BoundRect and FrameRect should be the same. The difference happens somewhere in opening the odt document.

MS Office puts differences between bounding rectangle (=BoundRect) and snap rectangle (=FrameRect) into the attributes wp:effectExtend in the file. Without my patch that was not done on export, with my patch LO writes them to file too. MS Office has no UI for that, but uses the values.

On import from docx the values from wp:effectExtend are incorporated into the wrap distance from text, because LO has nothing comparable to "wp:effectExtend". In this case you get a top distance, in UI 0.02mm, which extends the wrap area of the shape so that there is not enough space for the characters of the third text line.

So the problem is not directly in my patch, but the question is, why the bounding rectangle is shifted up on opening the odt-file.

Another question is, whether my patch can/should workaround the underlying problem.
Comment 7 Telesto 2021-12-30 18:55:19 UTC
I guess something is off with the file itself.

It has drawing object frame & a image frame on top of each other. Still no clue how this happened. But well DOCX export converts frames to Drawing objects. I obviously used a quite a number of master builds

So the file itself might be an anomaly
Comment 8 Regina Henschel 2021-12-30 20:04:56 UTC
Created attachment 177215 [details]
Only Rectangle

The double "frame1" comes in with ODF -> docx -> ODF. But the problem exists with a pure rectangle too, see attachment.

Nevertheless the way an image with caption frame is exported to docx is questionable and needs improvement for better ODF -> docx -> ODF. But that would be a separate issue.
Comment 9 Justin L 2023-06-08 00:36:35 UTC
repro 7.6