Bug 115625 - FILEOPEN DOCX: Table placed on wrong position because of Frame Wrap
Summary: FILEOPEN DOCX: Table placed on wrong position because of Frame Wrap
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Hardware: All All
: medium normal
Assignee: Not Assigned
Whiteboard: target:7.6.0
Keywords: filter:docx
: 136270 (view as bug list)
Depends on:
Blocks: DOCX-Textbox
  Show dependency treegraph
Reported: 2018-02-11 06:26 UTC by Kevin Suo
Modified: 2023-08-30 11:04 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

test.docx (33.07 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-02-11 06:26 UTC, Kevin Suo
screenshot good (7.41 KB, image/png)
2018-02-11 06:27 UTC, Kevin Suo
screenshot bad (9.00 KB, image/png)
2018-02-11 06:27 UTC, Kevin Suo
Test compared MSO LO (67.66 KB, image/png)
2020-10-02 08:54 UTC, Timur
test.docx resaved in MSO (34.24 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-10-02 08:56 UTC, Timur

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Suo 2018-02-11 06:26:13 UTC
Created attachment 139768 [details]

The attached sample DOCX file contains a text frame, and below the text frame is a table. If I open it with MSO 2010, the text frame appears above the table without intersection. However, when I open with LibreOffice, the text frame is "intersecting" with the table.

Steps to Reproduce:
1. Open the attached test DOCX file.

Expected Result:
See screenshot "good". This is the result when open with MSO 2010.

Current Result:
See screenshot "bad". this is the result when open with LibreOffice.

Build ID:60bfb1526849283ce2491346ed2aa51c465abfe6
CPU 线程:4; 操作系统:Linux 4.14; UI 渲染:默认; VCL: gtk2; 
区域语言:zh-CN (zh_CN.UTF-8); Calc: group
Fedora 27 x64.
Comment 1 Kevin Suo 2018-02-11 06:27:38 UTC
Created attachment 139769 [details]
screenshot good
Comment 2 Kevin Suo 2018-02-11 06:27:59 UTC
Created attachment 139770 [details]
screenshot bad
Comment 3 Kevin Suo 2018-02-11 07:21:44 UTC Comment hidden (obsolete)
Comment 4 Kevin Suo 2018-02-12 01:37:33 UTC Comment hidden (obsolete)
Comment 5 IWAMOTO 2018-02-19 06:39:39 UTC
This was reproduced in the following environment.

Version: (x64)
Build ID: 60bfb1526849283ce2491346ed2aa51c465abfe6
Locale: ja-JP (ja_JP);
OS:Winsows7 Home Premium x64
Comment 6 Timur 2020-10-02 08:54:49 UTC
Created attachment 166029 [details]
Test compared MSO LO

Repro LO 7.1+. This was never fine, in OO there was no frame, later frame was wrong and this look is from LO 4.1.
It's not Text Frame Placed on Wrong Position, but rather table placed wrong due to frame wrap. 
Test DOCX is 2007 but same if resaved in MSO as new.
Comment 7 Timur 2020-10-02 08:56:16 UTC
Created attachment 166030 [details]
test.docx resaved in MSO

The same as 2007 DOCX, but let's keep here for test.
Comment 8 Silvestr VS 2022-05-04 20:58:39 UTC
Reproduced in 

Version: / LibreOffice Community
Build ID: 465c3ad95059f0efa13c8027f7383c4d20a5b2ff
CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb)
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded

Text field is still overlapping with the table both in original file and in the sample from comment #7.
Comment 9 Justin L 2023-03-15 21:07:25 UTC
This kind of bug report is duplicated several times. Apparently LO doesn't really consider a table something that needs to be affected by wrapping.
Comment 10 Justin L 2023-03-17 20:18:12 UTC

*** This bug has been marked as a duplicate of bug 76022 ***
Comment 11 Commit Notification 2023-03-24 18:25:56 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":


tdf#115625 tdf#76022 sw table: CalcFlyOffset: get correct surround for textbox

It will be available in 7.6.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:

Affected users are encouraged to test the fix and report feedback.
Comment 12 Justin L 2023-03-24 21:20:09 UTC
This particular document is fixed by the patch, but bug 76022 (of which this is a duplicate) is a bigger problem.
Comment 13 Kevin Suo 2023-03-27 01:41:40 UTC
I mark this as Fixed instead of Duplicate per comment 12.
Comment 14 Gabor Kelemen (allotropia) 2023-08-30 11:04:15 UTC
*** Bug 136270 has been marked as a duplicate of this bug. ***