Issue 23997 - Footnotes cause page breaks and page or column layout to be destroyed
Summary: Footnotes cause page breaks and page or column layout to be destroyed
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: OOo 1.1 RC5
Hardware: All Linux, all
: P3 Trivial with 1 vote (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
: 114169 (view as issue list)
Depends on:
Reported: 2003-12-30 23:22 UTC by carstenklein
Modified: 2013-02-07 22:38 UTC (History)
1 user (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description carstenklein 2003-12-30 23:22:05 UTC
Consider a two column or one column page which has footnotes. The page is
already layouted so that it's layout items (text/objects) fill up most of the
space the page provides.

Now, add a footnote and start editing it. The footnote will now expand it's
height according to the text being entered. It will expand until it causes the
page break or re-layouting of the elements on the page, then it will itself
break up and consume space on either the next page or next column. 
This causes the original layout to be destroyed and, eventually causes at least
one page break. I don't necessarily think that this is intentional ;-)


Before breaking the layout, the footnote should only be allowed to expand in
space (in height) to what is available on the current page, then it should
itself resolve to a more pro-active behaviour in that it should break up and
continue either on the next page or column instead of breaking the layout.
Comment 1 rblackeagle 2003-12-31 03:47:46 UTC
The behavior you mention as a problem is common to most word processors.  I have
had some problems with MS Word moving entire footnotes two or three pages away
when they got too big.  With OOo, I don't have that problem,but I do have to
consider the effects of an excessively long footnote.

The problem you mention suggests a solution, and that would be to permit split
footnotes at the user's option.  Once the footnote messed up the layout, I would
like to have the option to remove a line of text to get my layout back and be
able to right-click and have the option to continue the footnote on the next
page rather than mess up my layout.  

Alternatively, as you suggest, the layout would be considered sacrosanct by the
footnote frame so it would automatically become a continuing footnote.  The
problem with that is seen in the situation where the footnote is the last page
of a section and now the continuation is on the first page of the next section
-- something likely NOT wanted.

What I have seen in some works is a blank page with the footnote continued on
the blank page for the last situation.

As I look over the options, I prefer the one where footnotes cannot change a
basic layout but automatically extend to continuing footnotes on a blank page or
column if a new section immediately follows the column or page that contains the
footnote.  For publishers, this option competes with the one where the footnote
is on one page and the text continues on an additional column or page.
Comment 2 h.ilter 2004-01-06 10:11:04 UTC
Reassigned to BH
Comment 3 gulliver666 2004-09-18 15:11:32 UTC
I have a problem with OOo writer moving entire footnotes to the page after the 
footnote rather than the page on which the footnote anchor appears. Yes, I have 
also had this problem with MS word.

I have tried everything I can think of in the "text flow" style section.

I would do anything to have ALL of ALL the footnotes on the same page as their 
anchors. Is this not possible? If not, does anyone know when this issue might 
be fixed?

thanks, Matt

for reference, this issue may be related also to issue 29680 (May 2004)
Comment 4 bettina.haberer 2010-05-21 14:45:49 UTC
To grep the issues easier via "requirements" I put the issues currently lying on
my owner to the owner "requirements". 
Comment 5 michael.ruess 2010-08-30 14:09:53 UTC
*** Issue 114169 has been marked as a duplicate of this issue. ***