https://issues.apache.org/bugzilla/show_bug.cgi?id=44328
--- Comment #9 from Andreas L. Delmelle <adelme...@apache.org> 2011-04-01 15:03:20 EDT --- (In reply to comment #8) > One scenario I still need to look into is the case of tables/list nested in > blocks. All seems to work pretty well when they are direct flow descendants, > but I somehow still expect trouble... Pondering some more, I think that all will work splendid as long as it is all single-line blocks, which most of our list/table tests consist of. As soon as we get multi-line content, the game will change. If we have a table/list nested in a block, we generate merged boxes for the table or list content, respecting the widows/orphans constraints of the descendant blocks. The latter means that lists/tables, by design, now always generate multi-line boxes as their first/last elements, which the higher-level BlockLM will take to be single lines, to which it applies its own constraints... That may lead to unnecessarily keeping together the first N table rows, and in some extreme cases, move entire tables/lists to their own page. As for the best way to avoid it, I don't like the idea of checking for instanceof TableLM or ListBlockLM in BlockLM, but would not like to move the problem to those former classes either, since it is ultimately a shared concern between lists and tables. Perhaps, a special type of box that offers easy access to the maximum number of lines contained in it? We could then, instead of just incrementing by one, increase the boxCount with that number... I'll see if I can whip up a proof-of-concept and already add the necessary logic to the BlockLM, then later adapt the other LMs. I also still have to generate a scenario where the above would have a discernible and at the same time undesirable impact. It would likely involve a few levels of nesting before it becomes really annoying... -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
