Bug 73977 - Other: Increase available footnote area to support traditional Arabic, Urdu, and Persian typesetting
Summary: Other: Increase available footnote area to support traditional Arabic, Urdu, ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
: 157782 (view as bug list)
Depends on:
Blocks: Footnote-Endnote
  Show dependency treegraph
 
Reported: 2014-01-23 14:16 UTC by AtaRafi
Modified: 2024-01-25 15:19 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
example of a problem (28.49 KB, application/vnd.oasis.opendocument.text)
2016-05-27 04:15 UTC, Ishayahu
Details
example in docx. It looks like here it is ok (19.58 KB, application/zip)
2016-05-27 04:20 UTC, Ishayahu
Details
One Section of Book (56.17 KB, application/vnd.oasis.opendocument.text)
2023-10-14 21:37 UTC, Richard Moreno
Details

Note You need to log in before you can comment on or make changes to this bug.
Description AtaRafi 2014-01-23 14:16:33 UTC
Problem description: 
Traditional Arabic books often have larger footnotes. Usually I have to work with Arabic Books. These books have a lot of footnote text. Sometimes a SINGLE footnote continues to two or more pages.

This is very common in Arabic, Urdu and Persian traditional books. I mean we don't have any choice, we can't work with small footnotes area.

When i have large footnotes, they only occupy 78% of my page, the rest of page stays neat, that's not reasonable nor it looks good.

I want to have maximum footnote area, or at least 90% of the page.

And I want Writer to have a DOTTED line in a page that does not have main content, but only footnote text. What i mean is, if a page has a lot of footnote text (continued from previous page), commonly this page has a dotted line at the top, then the "separator" and then the footnote text.

Current behavior:
Maximum footnote area is not available in writer.

Expected behavior:
Writer should have the ability to give maximum footnote area, or say 90% area of the page.
Operating System: Windows 7
Version: 4.1.0.4 release
Comment 1 AtaRafi 2014-01-23 14:27:33 UTC
Behavior: Enhancement
Comment 2 Owen Genat (retired) 2014-01-24 05:23:10 UTC
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.
Comment 3 Ishayahu 2015-06-29 12:17:57 UTC
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
Comment 4 Bartosz 2016-05-26 23:32:11 UTC
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.
Comment 5 Ishayahu 2016-05-27 04:15:01 UTC
Created attachment 125316 [details]
example of a problem
Comment 6 Ishayahu 2016-05-27 04:20:25 UTC
Created attachment 125317 [details]
example in docx. It looks like here it is ok
Comment 7 Bartosz 2016-06-08 15:52:54 UTC
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
Comment 8 Xisco Faulí 2017-06-12 11:59:28 UTC
Changing version back to the earliest affected version.
Comment 9 Xisco Faulí 2019-11-29 13:28:29 UTC
Changing priority back to 'medium' since the number of duplicates is lower than 5
Comment 10 ajlittoz 2023-10-14 08:22:40 UTC
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.
Comment 11 Mike Kaganski 2023-10-14 09:20:29 UTC
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.
Comment 12 Richard Moreno 2023-10-14 21:37:08 UTC
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
Comment 13 ajlittoz 2023-10-15 12:24:40 UTC
(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.
Comment 14 Richard Moreno 2023-10-16 12:56:42 UTC
(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.
Comment 15 Buovjaga 2023-10-27 13:27:53 UTC
*** Bug 157782 has been marked as a duplicate of this bug. ***
Comment 16 Richard Moreno 2024-01-25 15:19:29 UTC
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?