Keiron Liddle wrote:
I can't visualise the flow of control here. I presume that the break (possibility?) is generated at, say, line-area building level.True, but I had in mind that any such approach will be built on the fact that any layout is, in some sense, tentative. Rhett raised the question some time ago of a means recording (and scoring) intermediate results, something which will be an essential element of such a solution.
At this stage, I would tend to think not of doing every possible layout, but of following the "optimum" values to perform initial layout, and then testing the result for "goodness". The minimum-maximum range provides the slack - within the context of the spec - for applying whatever other set of layout tuning algorithms that FOP implements.
The idea I am working with (of which I have prototype working) is that a break is after a line. For this break it finds the BPD distance from the top down (flow layout manager) from the start of the page to the current break.
[Is this always based on knowledge of the IPDim, or does the possibility exist of not knowing IPDim, but being prepared to report upward on the possibilities for IPDim?]
Does the information about this break then percolate back up to the flow-level layout manager? Is the BPDim from top of page reported back to the line-area level, or maintained at the flow manager level?
It also finds the keeps from the current break position, looking at parent layout managers and next layout managers for keep with previous. A best break is found based on these two values. A next break is then found, since we don't know we have a best until there is a worse break. This can be done for all pages in the page sequence or until forced break.This implies that the answer to my previous question is that the BPDim comes back down to the line-area level, and that keeps are resolved between adjacent line-area builders. Your notes here seem to be referring to column and page breaks. At what level is the contention between two or more line-area builders for "best break" resolved?
Then if for example we want to find the optimum break. There is also the possiblity to get the next break within a context (which invalidates all further breaks) or previous break.Is this invalidating of further breaks something which is instigated from a higher level?
I am quite confident that this will work well. Footnotes and before floats suddenly become easy. Keeps are quite easy also.
It would be good to get some more illustrations of the way these will work.
The only drawback is that it constantly needs to find the child layout manager that applies to a given break and that finding the BPD distance could be time consuming in some circumstances. Optimisations should help a bit.I think this is similar to what I refer to as threading the tree to establish which areas are contiguous in the output, both for keeps and space specifiers resolution.
I would see these being arranged as a set of heuristics - for want of a better word - that are applied in a structured fashion to detected layout conflicts of particular types. What comprises a conflict would be determined by those configurable parameters.
In the initial version, we only need to provide for the most basic of these, as long as the mechanism is general enough to allow for refinement.
I am hoping that making the breaks simple and easy to find certain properties from any position will help us to explore what to do next.
Peter
--
Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
