Bug 164747 - WRITER: widow/orphan disabled in footnotes
Summary: WRITER: widow/orphan disabled in footnotes
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
24.8.4.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Footnote-Endnote
  Show dependency treegraph
 
Reported: 2025-01-17 15:26 UTC by ajlittoz
Modified: 2025-07-14 12:00 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Widow note line on next page (43.60 KB, application/vnd.oasis.opendocument.text)
2025-01-17 15:26 UTC, ajlittoz
Details
PDF version for reference (70.48 KB, application/pdf)
2025-01-17 15:31 UTC, ajlittoz
Details
PDF Export (160.10 KB, application/pdf)
2025-01-17 18:32 UTC, Telesto
Details
Optional: Example with Palatino Linotype font (1.01 MB, application/vnd.oasis.opendocument.text)
2025-07-12 13:00 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ajlittoz 2025-01-17 15:26:50 UTC
Created attachment 198595 [details]
Widow note line on next page

Widow/orphan controls in paragraph styles are used to dictate how many lines of a split paragraph are tolerated at bottom (orphan) and top (widow) of pages.

It looks like these parameters are not taken into account in footnotes.

In the attached document, note 3 is the last one on the page. It is 3 lines long. Unfortunately there is room for only 2 lines and line 3 (a single word!) is flushed into next page note area.

If widow setting were applied, the whole note would have been flushed to next page.

I understand that the matter may be more complicated because note 3 anchopr is located on the **last** line of text in the page which incidentally is also the last line of the paragraph.

There are then 2 possibilities:

- the note is simply flushed to next page
The settings turn the note into an atomic 3-line block. But this sets the anchor and note on separate pages which Writer tries to avoid (except when footnote area overflows as a consequence of note volume).

- the note and its anchor are flushed to next page
This may cause other issues in cascade. Here the anchor is on the last line. Consequently, this last line can't be moved without consideration for widow parameter. With the paragraph style configuration, 2 lines must be moved to avoid a widow. Doing so, reduces the height of the paragraph and orphan parameter must also be looked at. If it is "violated", the full paragraph must be moved.

The attached document is an excerpt of a very large work. This widow/orphan problem occurs many times. Since there is a publishing deadline, I'd like to find a workaround.

Version: 24.8.4.2 (X86_64)
Build ID: 480(Build:2)
CPU threads: 4; OS: Linux 6.12; UI render: default; VCL: kf6 (cairo+wayland)
Comment 1 ajlittoz 2025-01-17 15:31:20 UTC
Created attachment 198596 [details]
PDF version for reference

Since the layout is highly dependent on text volume and font metrics, the PDF version is there to show the issue in case font substitutions changes the layout.

Don't update the TOC (the socument is a small excerpt of the original one). It consumes page space so that the offending note is on the last available text line and note is forced to split.

PS: this specific case can be fixed by erasing the empty paragraph below the TOC. However, I can't play the same trick in the narrative where there are no empty paragraphs.
Comment 2 Telesto 2025-01-17 18:32:50 UTC
Created attachment 198598 [details]
PDF Export

Attachment 198595 [details] looks different for me. 

A) There is footnote on page 1 for me (not in your PDF)
B) My footnote numbering restarts (not in your PDF)

Plenty of possible explanations
A) Wrong attachment?
B) Rendering different by OS?
C) Font substitution in play or or different font versions

Version: 25.2.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 94afced0195ef824e575176e33c79ca57484cd5c
CPU threads: 4; OS: Windows 8.1 X86_64 (6.3 build 9600); UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL threaded
Comment 3 ajlittoz 2025-01-18 13:04:16 UTC
(In reply to Telesto from comment #2)
> Created attachment 198598 [details]
> PDF Export
> 
> Attachment 198595 [details] looks different for me. 
> 
> A) There is footnote on page 1 for me (not in your PDF)
> B) My footnote numbering restarts (not in your PDF)
> 
> Plenty of possible explanations
> A) Wrong attachment?
> B) Rendering different by OS?
> C) Font substitution in play or or different font versions
> 
It is probably a matter of font substitution. Metrics are different. Part of the now last paragraph and complete following have been shifted to next page. There is thus ample space at bottom of page 3 for notes now numbered 1 and 2 (previously 2 and 3 on preceding page).

As I mentioned, this is very tricky and difficult to show. Try decreasing font size in Body Text to attempt to reproduce. My configuration is 11pt in Body Text and 10 pt in Footnote.

The main author chose Palatino Linotype which is not installed on my computer. I forced substitution to GUST TeX Gyre Pagella which is advertised as having the same metrics.

From a quick visual inspection, I'd say that your substitution has a taller line height. My version looks more compact and darker. You could also play with Body Text line spacing (setting it at ~80%?).
Comment 4 Vollbracht 2025-03-01 16:21:34 UTC
Just recognized this very problem. I have a paragraph with a long foot note resulting in a widow line in the end of the paragraph AND in the end of the foot note paragraph. I tried to solve the problem by avoidance of widow lines in the foot note paragraph (requiring 3 lines on next page) with no effect. That 3 lines requirement was just ignored.
Comment 5 Dieter 2025-07-12 12:16:57 UTC
I confirm it with

Version: 25.2.4.3 (X86_64) / LibreOffice Community
Build ID: 33e196637044ead23f5c3226cde09b47731f7e27
CPU threads: 12; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Vulkan; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: CL threaded

and wirth

Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: bfa28a257ae621747dddbb61f228705cf46079b8
CPU threads: 12; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL threaded

Steps
1. Open attschment 198595
2. If footnote three is not part of page 2 delete some text from th beginning until footnot 3 becomes part of page 2

Actusl result:
Line three of footnote 3 is on a new page; orphan/widow rule is not respected
Comment 6 Telesto 2025-07-12 13:00:48 UTC
Created attachment 201768 [details]
Optional: Example with Palatino Linotype font

So the issue not caused by font-substitution..

and already seen in
OpenOffice 2.2.1
Comment 7 Telesto 2025-07-13 10:12:19 UTC
@Mike Kaganski
Not sure who to ask. However it would be nice to have some developer input. Especially because the bug being present since the since the dawn of time. Is it simply gone unnoticed? Or is it to be expected for one reason or another?
Comment 8 Mike Kaganski 2025-07-13 12:43:01 UTC
I believe that it is to avoid the following situation:

1. There is a text with a footnote reference near the bottom of a page, but there is space for two lines of footnotes there;
2. The footnote takes three lines;
3. Its orphan/widow control demands the footnote to be moved to the next page as a whole;
4. But then the body text must move to the next page, too? And leave huge empty space at the bottom of this page?

I don't know what needs to be done here. If the existing logic is sane, then we should disable the controls for paragraph in the footnotes - but paragraph styles will still not make it obvious.
Comment 9 ajlittoz 2025-07-13 16:06:57 UTC
(In reply to Mike Kaganski from comment #8)
> I believe that it is to avoid the following situation:
> 
> 1. There is a text with a footnote reference near the bottom of a page, but
> there is space for two lines of footnotes there;
> 2. The footnote takes three lines;
> 3. Its orphan/widow control demands the footnote to be moved to the next
> page as a whole;
> 4. But then the body text must move to the next page, too? And leave huge
> empty space at the bottom of this page?
> 
> I don't know what needs to be done here. If the existing logic is sane, then
> we should disable the controls for paragraph in the footnotes - but
> paragraph styles will still not make it obvious.

I think this is the practical reason. And step 4 is probably worse than what is schematically described.

Can it be mitigated? I wanted to experiment to make a comparison between numerous huge notes overflowing available page space and isolated note (at bottom of page).

Unfortunately I stumbled on another bug: it looks like the presence of footnotes disables systematically widow/orphan processing on the last paragraph, no matter if it has notes or not, provided the note anchor is in this page (relevant in case notes overflow to next page).

Is this part of the same bug, i.e. perturbation of widow/orphan on last narrative paragraph? I can provide an example file, but should I report a different bug?