| Summary: | Using keep-together.within-column and break-after results in missing text | ||
|---|---|---|---|
| Product: | Fop - Now in Jira | Reporter: | Kostis Kapelonis <kkapelon> |
| Component: | Assignee: | 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
Created attachment 23603 [details]
Result PDF file
Created attachment 23604 [details]
Sample FO file that triggers the bug
Added testcase FOP
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 (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 } 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. (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 resetting severity from major to normal pending further review resetting P2 open bugs to P3 pending further review |