Keiron Liddle wrote:
On Sat, 2002-11-16 at 09:21, Rhett Aultman wrote:

It seems to me that there are (at least) two approaches: 1. A leaf on the
tree says "I am here, put me somewhere on a page", or 2. A higher-level node
(page-sequence) says "I have some space here, send me something to fill it."
3. 1 + 2.

Thinking that you can do 1. in isolation is, well, brain-dead. On the other hand, how does 2. handle auto table layout? The columns cannot be dimensioned at the very top until the last information about requirements is in from the very bottom. Then the decision is taken at the top, and percolates all the way back down again.<<

I agree that there's a combination of both approaches are necessary, but I'm not sure how 1 handles auto table layout all that much better. I did just wake up over an on-call issue, so maybe it's grogginess, but wouldn't auto-layout either way require reading the whole table first to divine column widths? I will concede that, under option 2, it's not clear if the table will fit in the proffered space until after the entire table is processed, meaning that a "purely 2" system is doing a LOT of looking ahead, just to keep up with itself. Is this the handicap of the second option you're referring to? Under the first option, the table can take care of itself, then demand to be placed somewhere, which has the benefit of less looking down the road but the deficit that there may not be room for it anywhere.

What if, instead, two passes were taken? The first pass would be for trying to find space for all of the objects with hard-and-fast space and size needs, and then the second pass would place objects that are more malleable. By taking two passes, it'd be possible to first divine the size of auto-layout tables, for example. Like I said...it's late and I was roused from bed, so I may have not really thought about this as much as I should, but this is brainstorming...


If possible I think we should try to avoid making multiple passes since
it can lead to loops etc. The table layout auto will need at least two
passes but this should be possible using the layout managers.

Is that a "should be" or an "is"? Given your recent concerns about the rapidly increasing complexity of your design, do you have a feasible solution for auto layout?

Multiple passes - in some sense - are unavoidable. This is most obvious in the case of auto layout, as described in the CSS documentation which is the actual reference for this stuff.

The general concept of layout managers is that a layout manager deals
with the breaks that the child layout managers create. So that it can
group together breaks when there is a keep together and only return one
break to the parent LM which is allowed against the keeps.

This can then be extended to the situation where it needs to break
within that keep, it will return the best available break.
The parent can then deal with it appropriately.
I think the idea is sound but there are some implementation questions
about dealing with keep with previous and other situations.

Now the real problems.

What happens for footnotes. A footnote takes space from the main
reference area. So we need some way of calculating the remaining space
given a potential footnote and the inline area (or line) that adds the
footnote. Do we pass the information all the way to the top and then get
an answer or is there some other way that the calculation can be
achieved where it is needed. Before you say thats simple, just subtract
it from the body bpd, well what happens if the footnote is inside a page
column. The height that the columns require needs to be calculated by
balancing the columns with the currently available areas, then you find
the space remaining with the footnote.
There are alos situations where the footnote is added where the whole
block must be added. Then it must wait until the block is complete
before saying if the block and footnote can fit.

Sometimes it needs to make a calculation with an abritrary ancestor
other times it needs to hold until another ancestor finds a valid break
before know if it will fit.
You have, of course, read my notes on this topic. If, by some mischance, you have not, you'll find them in the alt.design section of the web page. When you get around to migrating it to forrest, that is. When is that likely to be, by the way?

So how do we deal with all these things without making it really slow
and complicated.
I would suggest just getting it working. If that ever happens,
1) I will be pleasantly surprised
2) you can then worry about making it faster.

If it doesn't happen, then, when I have finished my work on properties, I will design and implement the layout engine, and it *will* work. Before then, however, the whole exercise may have been rendered academic by Sun.

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]

Reply via email to