https://issues.apache.org/bugzilla/show_bug.cgi?id=46905
--- Comment #2 from Andreas L. Delmelle <[email protected]> 2009-04-16 13:42:31 PST --- In the meantime, applied the patch locally, and started to look into the failing tests. First observations: - Very good starting point: refactoring the keep-logic based on a Keep object in the layoutengine that correlates to the KeepProperty in the FO tree definitely makes things a lot easier to read. The only thing that does not look entirely right IMO, is the addition of the methods to the BlockLevelLM interface. I think we can safely push it up to the LayoutManager interface, since it may prove handy in the longer term to fully implement inline-keeps as well. It is not yet possible, IIC, to keep two fo:inlines together on the same line. I'd make it an 'optional' method, so add an UnsupportedOperationException to the method signature for cases like BlockStackingLayoutManager (using IllegalStateException in the patch) - I see only 9 failed tests here at first glance... Could be missing one (?) - Re: the remark about the hacky nature of using the break-class of KnuthPenalty: How about creating a set of dedicated subclasses of KnuthPenalty (PageBreakPenalty, ColumnBreakPenalty...), rather than play with the base class member? That way, the parts of the code that use the base class can probably remain largely unaffected by the changes for now. Obviously, where necessary, we will then have to take care to instantiate the correct types of penalty, but it could ultimately lead to code that is easier to read The class hierarchy could reflect the real relationship between the different break-opportunities: a PageBreakPenalty is a ColumnBreakPenalty, which is a LineBreakPenalty, which is a special type of KnuthPenalty? OK, enough ranting, back to investigating the failing testcases. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
