Created attachment 200282 [details] Example document with glitchy table and screenshots from Word We experiences an issue with the table-in-table ODT(or DOC/DOCX if is saved as it from ODT) documents. The document contains a Table 1 with two columns and in second column there is a multi-line Table 2. On page 4 of attached document on Writer the rows of Table 2 are overlaps each other (regardless the settings, we tried different combinations of "split across" or "break across" on them). Page 4 (end of table) seems to display pretty well. The tables are one of possible examples from big document with similar objects. Most of them (in original doc) seems to be ok, but some of them shares the same behavior. But if we convert the table to DOC and open in Word it seems to be ok (screenshots are attached). (But if we open converted doc in Writer - the issue still remain). Tried to open a file on dev version of Writer - the problem seems to be reproduced there. The problem was found on Windows version of Writer, but for Linux build it is also reproduced.
Repro with Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7fac8458e35620b9855cc6c68a9675159a849b65 CPU threads: 8; OS: macOS 14.7.4; UI render: Skia/Metal; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded and with Version: 7.0.0.3 Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
No overlap but table being split differently with Versie: 6.4.0.2 (x86) Build ID: 08d19fecdc7a2298d051e19cfdb7c35544855fc3 CPU-threads: 4; Besturingssysteem: Windows 10.0 Build 19045; UI-render: GL; VCL: win; Locale: nl-NL (nl_NL); UI-taal: nl-NL Calc: CL Adding bibisectRequest for some code-pointer.
Bisection of whether to overlap commit 8a21d5053d331160e4913dc80c045a454ec84de3 author Justin Luth <justin.luth@collabora.com> 2020-05-04 22:21:46 +0300 tdf#132642 sw layout: try2 emulate table kept-with-next not splitting This adjusts my LO 5.2 code for tdf#91083 that tried to emulate the table's keep-with-next property which doesn't have a matching counterpart in MS formats. I always confused myself trying to understand what my year-long coding attempt was trying to do. This seems much understandable, and efficient. The big clue was that it affected non-MS formats - which was unintended. Change-Id: I7886e52430cb34799e25f7fcf73500e28bbe2a55 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93443
@Justin, Would you mind to asses if this is regression or not. Overlapping text - seen here - for table in table is surely a bug. However, tables being split aggressively with few row on each page isn't nice either
One key for Denis is "keep with next paragraph". This is the property that is set in your big table's "Text Flow" properties - and I doubt that you really want to keep that multi-page table connected to the following (empty) paragraph. [However, that doesn't solve the problem...] The big question (in regards to regression) is what did it do in LO 5.1 before all of my messing around. And the answer to that question is that basically, it looks the same as today. How about after my initial changes? (I look at 5.4). In that case, although the content isn't overlapping, it is "hidden at the bottom of the page". Basically, it looks like a table-in-table can't span pages. Additionally, the table has split so that the first two rows are on page 4, and the table-in-table row starts on page 5. So that isn't right either. So now lets go to 7.0 before my commit. Basically the same as 5.4. And after my commit we are back to basically the same as 5.1. Now the table-in-table is again splitting across pages (good), but not all of the rows are being pushed out to a new page. (I notice a slight delay when I get to that page before it is displayed, so it is probably hitting a layout loop.) So, definitely a layout bug. But not a regression. (I reproduced the same result in OOO 3.3)
Created attachment 200480 [details] smallExampleMinimized.docx: a 2-page example that manifests slightly differently In this minimized example, you can really see the difference by switching between View - Web and View - Normal. (You also see text popping in and out as you interact with the various cells.) I removed the header/footer and non-table content to simplify the example (and to rule out that they played some factor). It seems to be simply a table-in-table issue - somehow related to the last column - which has more rows than the previous columns. (If you delete the last column, it looks better.)
@Justin Thanks for the extensive analysis and smaller example FWIW. Your example opens fine (after DOCX to ODT save) with OpenOffice 2.2.1. Doesn't open in OpenOffice 2.3.0 (or I didn't wait long enough) and the broken layout is present in OpenOffice 2.4.3 So assume it started with the introduction of the New Table Model mentioned in: https://www.openoffice.org/development/releases/2.3.0.html swnewtable: New table model (row/col span) for Writer tables