When a table overlaps with a fly frame, Writer creates a fly portion inside the relevant cell frame (increasing its height), and Word shifts the table down. Both are valid approaches, but the rendering result is different in case the table has a border.
So keep the default unchanged, but in case the AddVerticalFlyOffsets compat flag (set by the Word importers) is set, avoid the overlap the Word way.
Note that the table frame uses the full width (available in the body) even for e.g. 50% width tables, so check for the overlap using the print area, which does not always overlap.
Finally, don't always require a valid frame area definition from the fly frame:
- the mentioned i#46807 bugdoc currently doesn't need that check
- the fly frame area definition becomes valid only after already positioning the table, leading to an overlap
Keep that check for the non-compat case, though.
Change-Id: I9202050befebf2efdbb5395ded6fcb52b378d8e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88724
fd7749fddc5a sw: fix handling of table vs fly overlaps in the AddVerticalFlyOffsets case
sw/CppunitTest_sw_core_layout.mk | 72 ++++++++++++++++++++++++++
sw/Module_sw.mk | 1 +
sw/qa/core/layout/data/table-fly-overlap.docx | Bin 0 -> 17718 bytes
sw/qa/core/layout/layout.cxx | 48 +++++++++++++++++
sw/source/core/layout/tabfrm.cxx | 30 ++++++++++-
5 files changed, 149 insertions(+), 2 deletions(-)