Behavior: Enhancement

Thanks for reporting the bug, however please do not confirm your own bugs. The point of confirmation is to allow a secondary party to verify the issue. I can confirm that the default "Not larger than page area" setting specified under Format > Page > Footnote tab appears to be set at ~78-79% range of the paragraph text area. The "Maximum footnote height" setting is similarly limited. The related AskLO thread is:

http://ask.libreoffice.org/en/question/28373/maximum-footnote-area/

Arch./Platform set to All/All as I see the same thing under GNU/Linux x86_64. Importance left at high as this affects traditional "Arabic, Urdu and Persian" typesetting. Would be good if a l10n expert could confirm this. Severity set to enhancement. Summary edited for clarity.

I have the same problem while translating hebrew books into russian. I too need footnote are to be 100% of page sometimes
OS win7x64
LO 5.0.0.0.beta1

I would like to fix that issue.
Could you please attach some example file with large footnote.
It will be great to have it both in "odt" and "docx" file formats.

Created attachment 125316 [details]
example of a problem

Created attachment 125317 [details]
example in docx. It looks like here it is ok

The footnote height could be set manually and with custom height.
Both are limited in theory by page height, but in practice there is some magic number which limit footnote height

I found that most of the UI is implemented there:
https://cgit.freedesktop.org/libreoffice/core/tree/sw/source/ui/misc/pgfnote.cxx#n35
5
There is nothing about maximum value, except:
     lMaxHeight *= 8;
     lMaxHeight /= 10; 
     // set maximum values
     HeightModify(*m_pMaxHeightEdit);

Unfortunately it is only changes maximum UI values which could be set via Format->Page...->Footnote...->Maximum footnote height.
It it not changing a maximum height of footnote at all.

I suspect that real limitation is implemented somewhere in:
  SwSaveFootnoteHeight
  SwTextFrame::ConnectFootnote

Changing version back to the earliest affected version.

Changing priority back to 'medium' since the number of duplicates is lower than 5

Not opening a duplicate for this bug. Confirming it is also important in "Western" languages too for specialised documents like university thesis or law analysis memos.

See for example https://ask.libreoffice.org/t/excess-blank-body-text-on-pages-with-footnotes-only-wasted-pages-and-increased-publication-cost/97024

Presently Maximum_footnote_height is limited to 80-85% of page area and Not_larger_than_page_area has implicitly the same limit while user would expect no limit.

Code pointer: SwFootnoteBossFrame::GetVarSpace in sw/source/core/layout/ftnfrm.cxx

> // To not fall below 20% of the page height
> // (in contrast to MSOffice where footnotes can fill a whole column/page)

This was that way since the beginning. I don't really know if changing this requires an introduction of a compatibility option (it will definitely change layout of existing documents, if not guarded by such an option - but is that actually bad?). So before making this an easyhack, this point needs clarification.

Created attachment 190220 [details]
One Section of Book

Linux Mageia Version 7
Version: 7.4.5.1
Build ID: 40(Build:1)
CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

American English Legal Treatise created with LO Writer 7.4.5.1 in .odt format with uniform default page and footnote definitions. Page size is user defined as 6" x 9".

A section may have a page or few pages of body text with 20-50 or more substantive footnotes. In the pages without body text LO Writer puts 2-3" of blank body text area. Adjusting Page Style->Default Page Style->Footnote->Maximum Footnote Height does not reduce the blank body text area.

The result is much wasted space increasing cost of printing.

Question: Is there another means to adjust Maximum Footnote Height ?

RDM

(In reply to Mike Kaganski from comment #11)
> 
> This was that way since the beginning. I don't really know if changing this
> requires an introduction of a compatibility option (it will definitely
> change layout of existing documents, if not guarded by such an option - but
> is that actually bad?). So before making this an easyhack, this point needs
> clarification.

Perhaps a way to mitigate the compatibility issue is to keep the present 15-20% reserve area for manually adjusted footnote area height and to remove limit when user chooses Not_larger_than_page_area.

(In reply to Mike Kaganski from comment #11)
> Code pointer: SwFootnoteBossFrame::GetVarSpace in
> sw/source/core/layout/ftnfrm.cxx
> 
> > // To not fall below 20% of the page height
> > // (in contrast to MSOffice where footnotes can fill a whole column/page)
> 
> This was that way since the beginning. I don't really know if changing this
> requires an introduction of a compatibility option (it will definitely
> change layout of existing documents, if not guarded by such an option - but
> is that actually bad?). So before making this an easyhack, this point needs
> clarification.

This maximum footnote problem is significant for a book that has 2500+ pages most of which are footnotes--very common for a law treatise.  The bug increases number of pages due to the 12-20& of blank text area. The cost of publishing the work increases proportionately. If LO Writer cannot be efficiently used for such works, it should make the limitation more well kown so that writer can select another word processor.

*** Bug 157782 has been marked as a duplicate of this bug. ***

I have a University-level programmer willing to investigate and to create a custom version for this problem since LO does not seem interested.

If anyone interested in sharing in costs (which I do not yet know), send me an email?