Created attachment 160225 [details] sample file issue found while creating unittest for bug 66496 Steps: 1. Open sw/qa/extras/ooxmlexport/data/tdf66496.docx -> document has 1 page 2. Export to DOCX 3. Reopen -> Document has 2 pages Reproduced Version: 7.0.0.0.alpha0+ Build ID: cf36fe5eb41910c26d58fb25e54ccf2e0ee01365 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
The import part was fixed by https://cgit.freedesktop.org/libreoffice/core/commit/?id=dff829e863fd05bedd5bcb713cd80c10fa582932. Before this commit, the document has 2 pages at import time @Justin, I thought you might be interested in this issue. For the unittest, you could reuse https://cgit.freedesktop.org/libreoffice/core/commit/?id=dff829e863fd05bedd5bcb713cd80c10fa582932
There is an extra CR added in each footnote for each save, which is the ultimate problem here I expect.
actually, it is on import that the extra CR is added. Probably this is another case for bRemove - but that is getting ridiculous...
This sample file has footnotes consisting of tables (which are not seen until I wave my magic cursor over them - Ubuntu 16.04 and 20.04). In sw flowfrm.cxx, I see this patch of code: SAL_WARN("sw.core", "Tables in footnotes are not truly supported");
Seems to me that only now is import correct, with 1-row tables in footnote, must be seen first with MSO. https://git.libreoffice.org/core/commit/e11c51eefe8c3210cef2b5850f401ba67a401d01 But bug remains, there's additional spacing after the first table. Something like screenshot attachment 170812 [details] in bug 95806.
Created attachment 170813 [details] sample compared MSO 2016 and LO 7.2+