Response Below.

-----Original Message-----
From: Peter B. West [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 15, 2002 7:25 PM
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'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" 

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.


I'm in agreement there.

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

Reply via email to