[Moving to fop-dev]

Thanks Pascal,

I couldn't mark the existing Jira entry as [PATCH], as I am not the original 
submitter of the issue - I cannot edit the subject. I attached the diff to the 
issue.

As to the tests - I'd like to get the patch reviewed first - if it is the 
"right thing to do". Then I can create a minimal layout test.

Regards,
Alexey.

On Thursday, September 19, 2013 09:11:56 AM Pascal Sancho wrote:
> Hi,
> 
> 1st, thanks for your proposal, all contributions are welcome.
> 
> Yes, this list is still alive, while activity is a little bit lower
> than the past.
> 
> Note that for FOP internal development, there is another list, more
> appropriate: fop-dev (follow [1]); you are welcome there ;-).
> 
> About submitting a patch, you should either open a new Jira entry, or
> change the existing one ([2]) to turn it into a patch entry (see [3]:
> submitting a patch).
> 
> Adding a test case to complete the patch is a good practice, so if you
> can add it, this will help in the merge process.
> 
> [1] http://xmlgraphics.apache.org/fop/dev/#mail-fop-dev
> [2] https://issues.apache.org/jira/browse/FOP-2106
> [3] http://xmlgraphics.apache.org/fop/dev/#patches
> 
> 2013/9/19 Alexey Neyman <sti...@att.net>:
> > Hi all,
> > 
> > I hope this list is still alive... as there has not been any reaction to
> > my
> > previous posts.
> > 
> > Attached is a patch that resolves the issue for the .fo attached to
> > FOP-2106 issue, as well as with the document where I had the issue. With
> > that patch, all ~60 footnotes in my document have been placed where they
> > should've been, without any of them going to the previous page or
> > overlapping with the body.
> > 
> > The issue is that when the PageBreakingAlgorithm class backtracks to
> > handle a page break (via its parent, BreakingAlgorithm), it does not
> > reset the footnoteListIndex/footnoteElementIndex fields. As a result, in
> > the second pass the footnote position is not calculated properly - then
> > first/last element/list indexes on pagebreaks are not correct, and
> > footnote is placed on the page before one where it has been successfully
> > fitted. This happens when two conditions are met: (a) there is at least
> > one page break inserted before the problematic footnote, and (b) if not
> > for the footnote, the containing block would fit at the bottom of the
> > previous page.
> > 
> > I am not sure about s/insertedFootnoteLength/totalFootnoteLength/ change
> > in
> > createNode(). I haven't seen any immediate effect from this, but it looks
> > like the total length of all the footnotes should also reset when
> > BreakingAlgorithm backtracks to a previous active node. Feedback welcome.
> > 
> > If the patch is deemed acceptable, I could probably add a test case for
> > that issue.
> > 
> > Regards,
> > Alexey.

Reply via email to