Respone below.

-----Original Message-----
From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 19, 2002 5:06 AM
Subject: RE: Getting breaks: revisited

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

>> 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...

> 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.

I'm not sure how writing the thing to make two passes is more loop prone than making 
one pass, especially if each pass performs a different function.  For example, what if 
the first pass was designed only to gather information about the proposed layout 
options and the second pass was the actual process of layout, getting the opportunity 
to make its decisions from on high with total knowlege?

> 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.<

Yes, and I think that the system works pretty well for a lot of situations.  I'm not 
suggesting that it get chucked to the weeds.  A question this begs, though, is that is 
this design going to take us the whole way through?  In your own email here you bring 
up two cases where a LM's decisions have to be dependant upon more than just its own 

>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.<

This is what I meant, too, when I said that there are cases where the concern does not 
behave in perfect, unidirectional tree-like fashion, which tells me that there's 
design considerations to make, and maybe going outside of the box and thinking of the 
current tree of LMs as one part of the solution is indicated.

>So how do we deal with all these things without making it really slow
and complicated.<

Keeping it from getting complicated is definitely important, but I'm willing to accept 
"slow" in the name of also getting "correct".

Also, this may seem like an issue only to me, but I our next layout system must be 
free of infinite loops.  It is essential that enterprise users know their Tomcat or 
jBoss servers are not going to have to be restarted if some guy makes a screwup in his 
Servlet or MBean and accidentally triggers a special case in FOP that leads to a 
layout loop.  A process for recognizing when a constraint must be lifted in order to 
ensure the document processes is necessary, and I think it was Victor (though maybe 
Peter...) who pointed out that such a process leads to another problem- if you lift a 
constraint in one place, you have effects on the layout of the entire document, too.  
In order to handle this problem, the entire layout system needs the ability to not 
only spot the issue but to select the best resolution for it and then layout according 
to that decision.  

I've spent a lot of mental energy over the last several days trying to come up with a 
solution, and the only one I've come up with thus far involves creating a tree of 
alternative layout choices.  For an ideal document, there really isn't a tree.  For 
less-than-ideal ones, there would be a branch of the tree at every place a violation 
occurs, and there decisions would branch off with possibilities of how to resolve the 
problem.  If a decision creates even more woes, its branch would get deeper and 
deeper.  Finding the ideal set of choices to make in resolving an issue then becomes a 
matter of simply finding the shortest branch in a tree.  This is, in many ways, in 
parallel with the "LayoutPlan" approach previously mentioned.

But, to do this, they layout system needs to start out with a certain base set of 
knowlege about the layout of the document, and to me this implies that multiple passes 
are needed.  Maybe only one final layout pass is needed, and the current, tree-based 
layout mechanism would probably be a shoe in there.  Once the high-level decisions are 
made, it should be easy for the present layout mechanism to follow them.  Whatever the 
shape this takes, I still see a need for some forms of redesign of the current layout 
system, if for no reason other than I don't think that tweaks and special cases are 
enough to prevent the layout managers from getting caught in endless loops.

As I've said before, I feel like I'm just spouting hoohah, so take this with a grain 
of salt, but I think more mechanisms are needed in the layout system than what's being 
offered are necessary, and I'd rather have a slow and complex but loop-free and 
complete LM than a fast and simple but loop-prone and incomplete one.

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

Reply via email to