Description: I work frequently with tables that have 2 rows and many columns (5-10) that span many pages, the top row being a header that repeats on each page. I often need to insert footnotes into the table, both in the header row and in the second row. After inserting a few footnotes, I will inevitably experience problems with the display of the table. In the attached document, which is a sample of the kind of thing I work with daily, as soon as I inserted the third footnote, the table suddenly jumped to the second page and instead of spanning multiple pages, seems to think it's all on one page; the cursor will continue to go down below the displayed text. These problems disappear as soon as I set footnotes to display at the end of the document rather than on each page, but this is no solution, since I need footnotes to display on the pages themselves. This seems possibly related to https://bugs.documentfoundation.org/show_bug.cgi?id=125885 and https://bugs.documentfoundation.org/show_bug.cgi?id=120139. Steps to Reproduce: 1. Open the attached document; see that the table is displayed incorrectly. 2. Set footnotes to appear at the end of the document; see that the table displays correctly. 3. To try it from scratch: open a new document. 4. Write some text. 5. Insert a table with 2 rows and 10 columns, header repeating on each page. 6. Insert enough dummy text in the table to make it span multiple pages. 7. Start inserting footnotes at random places. It should very quickly mess up how the table is displayed. Actual Results: Table display is messed up; it moves to the second page, does not display all the text nor split it onto the next page correctly. Expected Results: Table and footnotes should be displayed properly. Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 156909 [details] Test document Here is the document that demonstrates that footnotes and long tables do not interact well.
Repro with Version: 6.5.0.0.alpha0+ (x64) Build ID: 42a1a1c6b91907f81e15066ffab219411f18c4db CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: GL; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL and with Versie: 4.1.0.4 Build ID: 89ea49ddacd9aa532507cbf852f2bb22b1ace28 and with Versie 4.0.0.3 (Bouw-id: 7545bee9c2a0782548772a21bc84a9dcc583b89 behavior is bit better in 3.5.7.2 and LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 Bug 125885 and bug 120139 are related. However, this quite a nice simple example.
@Michael Stahl, I thought you might be interested in this issue...
Dear William Friedman, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still a problem in: Version: 7.5.3.2 (X86_64) / LibreOffice Community Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
On Fileopen, the table and footnotes look good to me now. I can see the table moved to page 2 in version 6.1, but that has improved in recent version. However, using the steps: 1. Open File 2. Insert footnote inside table Or: 1. Open File 2. Tools > Footnotes/Endnotes settings > Footnotes > End of document > OK 3. Undo twice ... I can see the issues described: table starts on page 2, and much of it not displayed. Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e9a0c97de95688b2f86bbb4dd8c823af5442401c CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded