--- Comment #26 from Andreas L. Delmelle <>  2009-06-22 
13:30:03 PST ---

Closing in on completing this one. A real challenge, I must say... Just writing
out some observations, as it generally helps me get closer to the solution
(even if nobody replies ;-))

Diving deeper and deeper into the layout-loop: from the point of view of the
page-breaking, the code in BreakingAlgorithm is really, really misleading.
considerLegalBreak() contains a loop, but in practice, the body of the outer
for-loop is always executed only once. There's a number of those hidden
throughout the codebase, IIRC: judging purely from the code, you can hardly
keep track of the nesting. When debugging the same code, you suddenly realize
that those are all pseudo loops...
The difference between startLine and endLine is always exactly one. 
The basic process seems to be: 
- try adding another line, 
- compute adjustment ratio/difference/demerits, and 
- if the line does not fit, recover by considering the lastTooShort node as the
definitive break.

Does not really sound so 'total-fit' to me. Earlier breaks are never revisited.
For the duration of the main loop in findBreakingPoints(), there is always at
most one node active. If the last node is too long, it is removed and the
recovery mechanism comes into play.

What it means in terms of page-keeps nested in column-keeps, is that the node
corresponding to the break before the keep-context switch will have been
discarded, since it was too-short. There is no way to get that node back, apart
from going back to the first preceding penalty in a different keep-context and
recreating it. Either that or...
Using some additional overrides in PageBreakingAlgorithm to keep track of the
keep-context and remember that node brought me very close to a solution, but it
still causes unwanted side-effects in other cases.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to