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)
(earliest affected) release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
Whiteboard: BSA
Depends on:
Blocks: Footnote-Endnote
  Show dependency treegraph
Reported: 2014-01-23 14:16 UTC by AtaRafi
Modified: 2019-11-29 13:28 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

example of a problem (28.49 KB, application/vnd.oasis.opendocument.text)
2016-05-27 04:15 UTC, Ishayahu
example in docx. It looks like here it is ok (19.58 KB, application/zip)
2016-05-27 04:20 UTC, Ishayahu

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: 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:


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
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:
There is nothing about maximum value, except:
     lMaxHeight *= 8;
     lMaxHeight /= 10; 
     // set maximum values

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:
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