Description: 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
Created attachment 140409 [details] bug docx file
Created attachment 140410 [details] actual view
Created attachment 140411 [details] expected view
Confirmed in Version: 6.1.0.0.alpha0+ 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 <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...
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] WrongTableTextPlacement_COMPAT12_LAYOUTINCELL0.docx 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] WrongTableTextPlacement_COMPAT15_LAYOUTINCELL0.docx 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.)
Fix in gerrit: https://gerrit.libreoffice.org/c/core/+/130077
Attila Bakos (NISZ) committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6e8ae79176be1c34cadc833c8e521be19455fade 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: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Looks good to me. I close as Fixed. Thanks.
Verified in: Version: 7.4.0.0.alpha0+ (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