The text that normally needs to be in the table is placed outside the table.
Steps to Reproduce:
1.Open the WrongTableTextPlacement.docx
User Profile Reset: No
OpenGL enabled: Yes
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Created attachment 140409 [details]
bug docx file
Created attachment 140410 [details]
Created attachment 140411 [details]
Build ID: 2affed9bfd72628549df3049ed9f6e6a30fdb5b8
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3;
Locale: ca-ES (ca_ES.UTF-8); Calc: group
Created attachment 140428 [details]
How it looks in LibreOffice 4.3
The behaviour was slightly better before
author Miklos Vajna <firstname.lastname@example.org> 2013-12-03 11:59:42 +0100
committer Miklos Vajna <email@example.com> 2013-12-03 15:39:04 +0100
commit 57450afb768c085df0ba2344aa94b5f843060178 (patch)
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
although it wasn't perfect either, thus not adding the regression keyword
I hope it helps...
Repro 7.0+ as of 14.12.2020.
LayoutInCell=1, so the textbox should be placed inside the table.
Sample code for checking compatibilityMode can be found in bug 77794.
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.
Created attachment 161571 [details]
When compatiblityMode = 15 (word 2019-2013), then it seems to ignore the LayoutInCell value - always treating it as true.
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.
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.)