Estimated read time: 4 minutes
This post is part of a series to describe how Writer now gets a feature to handle tables that are both floating and span over multiple pages.
Multi-page floating tables and nested tables could not be combined so far. Instead we tried to lay out the outer table on multiple pages and all inner tables were still limited to a single page. In this part, you can read about removing this limitation.
Results so far¶
Regarding testing, the core.git repository has 73 files now which are focusing on correct
handling of floating tables (filenames matching
floattable-|floating-table-). This doesn't count
cases where the document model is built using C++ code in the memory and then we assert the result
of some operation.
Here are some screenshots from the fixes this month:
The first screenshot shows a case where not only a single floating table is split across pages, but also the table's only cell hosts an inner multi-page floating table. This is more complicated at a layout level, because we can't just move part of the table to a next page, which has no parts of the outer table yet.
The next screenshot shows a case where the inner floating table starts at the cell start of the outer table. The DOCX import case needed addition effort to get working, because as soon as the inner floating table's content is moved to the floating frame from the body text, the reference to the cell start at the outer table level was invalidated and the whole table conversion failed.
This screenshot shows a bug where multiple inner floating tables started at the cell start of the outer table. Handling this correctly on our end had to ensure that each (potentially multi-page) floating table gets its own unique anchor point, and this can be combined with nesting, with the "at cell start" special case on top of it. Once all three can be combined, a real-world documents gets its table instead of just having the content the of the table in the body text.
The last screenshot shows an editing session where we keep inserting new paragraphs at the start of the document, so new items are created at the end of the fly chain as needed, and old items are deleted at the start of the fly chain as needed. We had a bug here so that the content we wanted to move forward was inserted at the end of the document, leading to a weird selection that started at the document end and continued on a previous page. Now this works correctly: once the first page is full of empty paragraphs, the second page hosts the first row and half of the second row. The third page then can host the second half of the second row and the third row.
How is this implemented?¶
If you would like to know a bit more about how this works, continue reading... :-)
As usual, the high-level problem was addressed by a series of small changes:
- Related: tdf#156318 sw floattable: fix handling of vert orient == top
- tdf#156318 sw floattable: fix follow text flow handling on interactive edit
- sw floattable, nesting: fix layout crash
- sw floattable, nesting: fix position of the inner follow table
- sw floattable, nesting: fix PDF export
- sw floattable, nesting: fix overlap support
- sw floattable, nesting: fix DOCX export
- sw floattable, nesting: add DOCX import
- Related: tdf#55160 sw floattable, nested DOCX exp: fix inner tbl at cell start
- Related: tdf#55160 sw floattable, nested DOCX imp: fix inner tbl at cell start
- tdf#55160 sw floattable, nested DOCX imp: fix inner tables at cell start
- tdf#157005 sw floattable: fix missing format of next row in follow fly
- tdf#157119 sw floattable: fix moving master of split fly to next page
- tdf#157263 sw floattable: prefer join over split after moving fwd
- Related: tdf#126449 sw floattable: fix bad join of inline tbl with inner fly
- sw floattable: maintain the invariant that fly height is at least MINFLY
- Related: tdf#126449 sw floattable: fix bad position of in-table follow fly
Want to start using this?¶
You can get a snapshot / demo of Collabora Office 23.05 and try it out yourself right now: try the unstable snapshot. Collabora intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all of this work will be available in TDF's next release too (24.2).