Response Below. -----Original Message----- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: Friday, November 15, 2002 7:25 PM To: [EMAIL PROTECTED] Subject: Re: Getting breaks: revisited
>>Victor Mote 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... >>In the much more constrained context of Lout, Jeffrey Kingston describes the back and forward movement of the layout logic in, e.g., Section 2.5 of "The Design and Implementation of the Lout Formatting Language" <http://snark.ptc.spbu.ru/~uwe/lout/design.pdf>.<< Fascinating little reference. Thanks! >> > Again, I am ignorant (although I have read the related doc), but reading > between the lines makes me think that we are driven to the first option, > which I am betting makes dealing with the higher-level layout issues very > complicated. I'm also surmising that we probably can't do a good job (or at > least can't *know* that we did) until we get the entire page-sequence read > anyway, which means that we might be better off reading it in before we > start & then taking the second approach. FWIW. Actually, I hope to learn a > lot from Keiron's replies. Likewise. << I'm in agreement there. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
