[ 
https://issues.apache.org/jira/browse/FOP-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13774302#comment-13774302
 ] 

Alexey Neyman commented on FOP-1749:
------------------------------------

Vincent, all,

I debugged improper reset of footnote-related fields during restartFrom(); this 
was the cause for FOP-2106 issue.
As the attached minimal test case shows, however, this problem (which is also 
reported in FOP-1678) is not related
to page breaks - it happens even if the footnote is on the first page. In this 
case, getFootnoteSplit() is called
(and hangs) before any calls to restartFrom().

In this minimal testcase, getFootnoteSplit() is called in the following context:
- availableLength is 26000 (millipoints)
- the note list is: Box(0mpts), Penaly(INF), Glue(20000mpts), 
BlockBox(12000mpts)

The loop then tries to insert as much footnote content as possible. However, in 
doing so, it ignores the width of
the Glue element (as it adds the width only if !boxPreceding - and boxPreceding 
is true in this case), so by the end
of the note list splitLength is only 12000mpts out of 26000mpts available.

The problem is, as a comment below the loop rightfully states, that by the end 
of the loop somethingAdded is
always true - which indicates a flaw in the loop logic. The attached patch is 
an attempt to fix that loop:
- set somethingAdded to true only if we added a non-empty box;
- add the glue width before breaking out of the inner loop;
- change the condition in the outer loop to match the preceding conditional 
(which checked if all footnotes can be
added) to stop the loop as soon as the availableLength is exhausted.

With these changes, the page break is correctly determined at the end of the 
first block - the second block
with the footnote in it is placed on the second page. However, there's a 
problem with the generated AreaTree:

<footnote top-offset="38000">
 <block ipd="240000" bpd="12000" ipda="240000" bpda="32000" bap="0 0 0 0" 
space-before="20000">
  <lineArea ipd="240000" bpd="9250" ipda="240000" bpda="12000" bap="0 0 0 0" 
end-indent="233330" space-before="1375" space-after="1375">
   <text offset="0" baseline="7180" ipd="6670" bpd="9250" ipda="6670" 
bpda="9250" bap="0 0 0 0" font-name="sans-serif" font-style="normal" 
font-weight="400" font-size="10000" color="#000000">
    <word>X</word>
   </text>
  </lineArea>
 </block>
</footnote>

The <footnote/> is generated with top-offset="38000" - i.e., not including the 
Glue element (from margin-top="20pt" on
the footnote's fo:block), but the <block/> is generated with bpd="12000" 
bpda="32000" space-before="20000" - that is,
including the Glue element for 20000mpts.

Is it an artifact of missing space resolution between boxes in footnotes? How 
should this be fixed?
                
> [PATCH] infinite loop in footnotes (see also #47424)
> ----------------------------------------------------
>
>                 Key: FOP-1749
>                 URL: https://issues.apache.org/jira/browse/FOP-1749
>             Project: Fop
>          Issue Type: Bug
>          Components: page-master/layout
>    Affects Versions: trunk
>         Environment: Operating System: Windows XP
> Platform: PC
>            Reporter: Heidi Vanparys
>         Attachments: bug47424.patch, c.fo
>
>
> This patch solves the problem of an infinite loop in footnotes as reported in 
> FOP-1678.
> The infinite loop occurred in 
> org.apache.fop.layoutmgr.PageBreakingAlgorithm.getFootnoteSplit(int, int, 
> int, int, boolean).
> This patch does not solve the problem of another infinite loop in footnotes 
> as reported in bugs 48063 and 48162. This infinite loop occurs in 
> org.apache.fop.layoutmgr.PageBreakingAlgorithm.createFootnotePages(KnuthPageNode).
>  The test attached to 48063 is converted to a testcase and added to the list 
> of disabled testcases.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to