On Wednesday, January 29, 2003, at 03:26  PM, Peter B. West wrote:
I can't visualise the flow of control here. I presume that the break (possibility?) is generated at, say, line-area building level.
Yes, a break is only generated where it is necessary

[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?]
For that situation I suggest a slightly different approach based on the same break ideas.
If an LM needs to find the min/max IPD, for example table cell, then it will use getNextBreak to get the breaks from above and then look at the information. It can find the distance and constraints only within the table cell context.

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?
Only the best break is needed for the general break finding. It keeps going downwards until this break is found. Once found it returns to the top, ie. flow manager. The BPD is only on the break and can be found at any time from anywhere using a start and end break. State information is not stored on the line areas.

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?
As before the constraints can be found from anywhere at any time. So for page columns it can getNextBreak (doesn't invalidate since same IPD and page) calculate distance from top of column, calculate constraints. So the contention in this case is resolved by the page column LM.

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?
The stored breaks would be thrown away at a higher level.
But for the finding breaks it think it could actually be done when doing a find or getting the next break, it would check the context and determine if it is different from before.

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 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.
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 have attached the code, very rough.

Attachment: proto.jar
Description: Binary data

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to