Bug 116256 - DOCX Import: LAYOUT?: incorrect placement of textbox in table in floating frame, from ignoring LayoutInCell.
Summary: DOCX Import: LAYOUT?: incorrect placement of textbox in table in floating fra...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
4.3 all versions
Hardware: All All
: medium normal
Assignee: Attila Bakos (NISZ)
Whiteboard: compatibilityMode15 target:7.4.0
Keywords: bibisected, bisected, filter:docx
Depends on:
Blocks: WPS-Support DOCX-compatibilityMode-15 DOCX-Floatingtable
  Show dependency treegraph
Reported: 2018-03-07 07:43 UTC by Gülşah Köse
Modified: 2022-03-31 07:35 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:

bug docx file (20.64 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-03-07 07:44 UTC, Gülşah Köse
actual view (2.43 KB, image/png)
2018-03-07 07:45 UTC, Gülşah Köse
expected view (2.30 KB, image/png)
2018-03-07 07:45 UTC, Gülşah Köse
How it looks in LibreOffice 4.3 (2.19 KB, image/png)
2018-03-07 12:01 UTC, Xisco Faulí
WrongTableTextPlacement_COMPAT12_LAYOUTINCELL0.docx (20.09 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-06-03 11:55 UTC, Justin L
WrongTableTextPlacement_COMPAT15_LAYOUTINCELL0.docx (20.09 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-06-03 11:57 UTC, Justin L

Note You need to log in before you can comment on or make changes to this bug.
Description Gülşah Köse 2018-03-07 07:43:42 UTC
The text that normally needs to be in the table is placed outside the table.

Steps to Reproduce:
1.Open the WrongTableTextPlacement.docx

Actual Results:  
See actual.png

Expected Results:
See expected.png

Reproducible: Always

User Profile Reset: No

OpenGL enabled: Yes

Additional Info:

User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Comment 1 Gülşah Köse 2018-03-07 07:44:35 UTC
Created attachment 140409 [details]
bug docx file
Comment 2 Gülşah Köse 2018-03-07 07:45:04 UTC
Created attachment 140410 [details]
actual view
Comment 3 Gülşah Köse 2018-03-07 07:45:38 UTC
Created attachment 140411 [details]
expected view
Comment 4 Xisco Faulí 2018-03-07 12:00:08 UTC
Confirmed in

Build ID: 2affed9bfd72628549df3049ed9f6e6a30fdb5b8
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group
Comment 5 Xisco Faulí 2018-03-07 12:01:10 UTC
Created attachment 140428 [details]
How it looks in LibreOffice 4.3
Comment 6 Xisco Faulí 2018-03-07 12:02:47 UTC
The behaviour was slightly better before

author	Miklos Vajna <vmiklos@collabora.co.uk>	2013-12-03 11:59:42 +0100
committer	Miklos Vajna <vmiklos@collabora.co.uk>	2013-12-03 15:39:04 +0100
commit 57450afb768c085df0ba2344aa94b5f843060178 (patch)
tree 19a4c28083ee2414102d70db2fcf6bd8ec410799
parent ddbeaada1c7abb0fee88e709f3d6d824f06b39e0 (diff)
DOCX import: declare wps as a supported feature
This means in case we hit an mc:AlternateContent element, we will read
the mc:Choice branch of it, in case wps is the required feature, not the
mc:Fallback one, which contains the information in VML format (after a
lossy conversion).

although it wasn't perfect either, thus not adding the regression keyword

I hope it helps...
Comment 7 Timur 2020-02-27 12:41:05 UTC Comment hidden (obsolete)
Comment 8 Justin L 2020-06-03 11:51:03 UTC
LayoutInCell=1, so the textbox should be placed inside the table.
Comment 9 Justin L 2020-06-03 11:53:18 UTC
Sample code for checking compatibilityMode can be found in bug 77794.
Comment 10 Justin L 2020-06-03 11:55:49 UTC
Created attachment 161570 [details]

If layoutInCell=0, and compatibilityMode > 15, then the document should look the way that LO currently displays it.  This version of the file sets compat to 12, and LayoutInCell to 0.  Make sure this scenario still works after the fix.
Comment 11 Justin L 2020-06-03 11:57:33 UTC
Created attachment 161571 [details]

When compatiblityMode = 15 (word 2019-2013), then it seems to ignore the LayoutInCell value - always treating it as true.
Comment 12 Justin L 2020-08-25 11:12:43 UTC
There are lots of illegal things happening in this context. My dev environment easily crashes with messages like "doclay.cxx:1602: Found a FlySection but not a Format!"

The textbox is not well connected with its containing frame - so this is a messy bug.
Comment 13 Justin L 2020-11-10 07:46:57 UTC
I'm not sure if this is primarily a layout issue, but I think it is. The handles for managing the textbox seem to be in the correct position inside the table frame, but what is displayed is still outside of the table boundary.

(And yes, there really is a single cell table inside of a floating frame and that table contains a textbox.)
Comment 14 Attila Bakos (NISZ) 2022-02-17 15:04:40 UTC
Fix in gerrit: https://gerrit.libreoffice.org/c/core/+/130077
Comment 15 Commit Notification 2022-03-10 18:51:02 UTC
Attila Bakos (NISZ) committed a patch related to this issue.
It has been pushed to "master":


tdf#116256 sw: fix textbox position in floating table

It will be available in 7.4.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 16 Timur 2022-03-11 11:13:08 UTC
Looks good to me. I close as Fixed. Thanks.
Comment 17 NISZ LibreOffice Team 2022-03-31 07:35:06 UTC
Verified in:
Version: (x64) / LibreOffice Community
Build ID: a3988b2d147a2442b348d58b79dbd6e71472b7af
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win
Locale: hu-HU (hu_HU); UI: en-US
Calc: threaded