Bug 47145

Summary: Using keep-together.within-column and break-after results in missing text
Product: Fop - Now in Jira Reporter: Kostis Kapelonis <kkapelon>
Component: pdfAssignee: fop-dev
Status: NEW ---    
Severity: normal    
Priority: P3    
Version: 0.95   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
URL: http://www.mail-archive.com/fop-users@xmlgraphics.apache.org/msg12846.html
Attachments: Result PDF file
Sample FO file that triggers the bug

Description Kostis Kapelonis 2009-05-04 00:24:56 UTC
I am using FOP 0.95 (latest stable at the time of writing) and attached FO file.

I convert it to PDF with

fop -fo minimal.xml minimal.PDF

Expected output:

A PDF file with two pages with "Text on the first .." shown in the first page 
and "Text on the next..." shown in the second 

Actual Output:

A PDF file with two pages. Only the "Text on the first.." appears on the 
document. The rest of "Text on the next..." is completely missing (not shown at 
all).

I was told in the mailing list by Vincent Hennebert that this is a bug and that I should report it in bugzilla

Thank you.
Comment 1 Kostis Kapelonis 2009-05-04 00:25:52 UTC
Created attachment 23603 [details]
Result PDF file
Comment 2 Kostis Kapelonis 2009-05-04 00:30:22 UTC
Created attachment 23604 [details]
Sample FO file that triggers the bug

Added testcase FOP
Comment 3 Vincent Hennebert 2009-05-06 09:48:04 UTC
Thank you for your bug report and your simple example. From a quick debugging session I found out the following:

The problem lies in the sequence of Knuth elements that is generated for the block children of the table cell: there is a penalty with -infinite value for the forced break, immediately followed by a infinite penalty for the keep. The consequence is that when areas are added to the second page, the first encountered Position is a SpaceHandlingBreakPosition, that has no LayoutManager associated to it, which early terminates the addition of areas.

The bug is this second penalty that shouldn't be generated in the first place, since breaks win over keeps. There may be an opportunity to fix that in the same time as bug #46905.

Vincent
Comment 4 Andreas L. Delmelle 2009-05-06 10:16:07 UTC
(In reply to comment #3)
> The bug is this second penalty that shouldn't be generated in the first place,
> since breaks win over keeps. There may be an opportunity to fix that in the
> same time as bug #46905.

Agreed. As I remember from another similar issue I fixed recently in FlowLayoutManager, it could turn out to be a very straightforward fix. I'll see if I can confirm later tonight.
At some point in getNextKnuthElements(), the parentLM adds a break in between the sequences returned by two consecutive childLMs. It's likely to be a simple matter of :

if (!ElementListUtils.endsWithForcedBreak(returnedList)) {
  //add in-between break
}
Comment 5 Andreas L. Delmelle 2009-05-06 14:43:22 UTC
Confirmed: checking for endsWithForcedBreak() in TableCellLM resolves the issue in this case. The only thing worrying me somewhat is that we have a similar bit of code in BlockStackingLM. May be possible to consolidate those somehow.
Comment 6 Vincent Hennebert 2009-05-07 02:38:41 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > The bug is this second penalty that shouldn't be generated in the first place,
> > since breaks win over keeps. There may be an opportunity to fix that in the
> > same time as bug #46905.
> 
> Agreed. As I remember from another similar issue I fixed recently in
> FlowLayoutManager, it could turn out to be a very straightforward fix. I'll see
> if I can confirm later tonight.
> At some point in getNextKnuthElements(), the parentLM adds a break in between
> the sequences returned by two consecutive childLMs. It's likely to be a simple
> matter of :
> 
> if (!ElementListUtils.endsWithForcedBreak(returnedList)) {
>   //add in-between break
> }

I think a LayoutManager shouldn't generate a Penalty element for a break-before/after. That's the job of the enclosing LayoutManager, when its addInBetweenBreak method is called. It's there that all the information about break-after on the current childLM, break-before on the next childLM, keep-with-next/with-previous/together can be collected, and a proper Penalty element can (optionally) be generated. I say optionally because no element needs be generated at all if a break-after is set on the last block of a page-sequence, for example.
That's what I did in tables (see TableContentLM.getKnuthElementsForRowIterator) and it works pretty well.

Vincent
Comment 7 Glenn Adams 2012-04-07 01:37:35 UTC
resetting severity from major to normal pending further review
Comment 8 Glenn Adams 2012-04-07 01:42:40 UTC
resetting P2 open bugs to P3 pending further review