Created attachment 197895 [details] Footnote separator overlaps text Make sure to have "TeX Gyre Pagella" font installed. Open the attachment, and scroll down to end of page 2. In Version: 24.8.4.1 (X86_64) / LibreOffice Community Build ID: 1be9007f5d86a3741c366527d13e2970cbeef057 CPU threads: 24; OS: Windows 11 X86_64 (10.0 build 26100); UI render: default; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL threaded and in Version: 6.0.0.3 (x64) Build ID: 64a0f66915f38c6217de274f0aa8e15618924765 CPU threads: 24; OS: Windows 10.0; UI render: default; Locale: en-US (ru_RU); Calc: CL the text "baz" (formatted to keep with next), the first two lines of the paragraph below, and the footnote are all shown on the page 2, with no spacing between the text and the footnote, and the separator overlapping the text of the footnote. The problem seems related to the combination of the settings, including the widow/orphan control. It shows OK (the whole part starting from "baz" on the third page) in Version: 5.4.0.2 (x64) Build ID: 2b906d450a44f2bbe506dcd22c51b3fa11dc65fd CPU threads: 24; OS: Windows 6.19; UI render: GL; Locale: ru-RU (ru_RU); Calc: group
Created attachment 197896 [details] TeX Gyre Pagella font (GUST Font License)
Discovered in 24.8.3.2, Linux 6.11, VCL kf6 (cairo+xayland)
Created attachment 197898 [details] Screenshot of the problem
Reproducible with Version: 24.8.3.2 (X86_64) / LibreOffice Community Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Version: 25.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 0f3f3710280d2476425bb86bc2e065e3e7a82952 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 26100); UI render: default; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Latest version that works on the ones I have installed. Version: 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: es_ES BTW changing the bottom page size from 2 to 1.8 seems to work and restoring to 2.0 does not return to the bad behavior.
After save and reload the file, the bad behavior returns again, and no matter if it is saved as fodt of odt.
Since I am at the origin of the bug report (Mike Kaganski succeeded in reducing the test case to minimum; I thank him heartily), I'll try to clarify the context. The sequence of paragraph is as follows: - a heading, with _Keep with next para_ enabled, as is common with headings - a text paragraph with _Split across page break_ enabled, orphan and widow both set at 2 lines - a foot note is anchored in the text paragraph The text paragraph is 4 lines long. Text flow is such that page break occurs between lines 2 and 3, as is expected from orphan/widow settings. The note is anchored on the second line. As you see, everything is very close to page bottom; so close, there is not enough room for the note. But there is nevertheless some small room. Writer then attempts to layout the footnote. It creates the separator and now there is no longer any room. However, since the separator has already been issued, the note is also inserted from the very bottom, extending upwards, thus overlaying text. What is expected? A note is supposed to appear on the same page as the anchor. This means that page break should be moved one line upwards so that the footnote'd line is sent on next page. But this conflicts with orphan setting requiring at least 2 lines. Then the first paragraph line should also be sent to next page. This leaves the heading alone at bottom of page. Its _Keep with next_ parameter requires it to be on the same page as the text paragraph. Consequently, the header should also be sent to next page. This is what seems to be done in 5.4.0.2. This is a sensible solution to reconcile all requirements. It looks like later releases consider that the space created at bottom of page is now high enough to accommodate the heading and the paragraph. Which is true when you put aside the footnote. So, the layout algorithm should be analysed to see how footnotes are handled in this pathological case. Note there is a single footnote which is discovered very late, i.e. on the very last line of the page. It is possible that having another note before this one would avoid the issue because space allocation for notes would have already begun.
I possibly reported the same bug as bug 164709, not remembering this one.
This is a regression from the following commit. Adding CC: to Michael Stahl. https://cgit.freedesktop.org/libreoffice/core/commit/?id=2e39e519767d58a20829baca2fb0a2418b70f772 author Michael Stahl <mstahl@redhat.com> 2017-11-03 21:48:37 +0100 committer Michael Stahl <mstahl@redhat.com> 2017-11-03 22:50:26 +0100 sw: ODF import: prevent shapes from inheriting paragraph default margins