On Tue, 2002-11-19 at 16:57, Rhett Aultman wrote:
> 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?

I can't really see what you could find out on a first pass that does not
do some sort of layout. I suppose it is a question of what exactly we
mean. Currently it sort of does more than one pass, but only the first
pass reads the fo and sorts out most of the layout.
When it is reset then it will reflow the inlines, lines and blocks.

An idea I am thinking of is reseting based on change of page or ipd. So
that it is possible to only reflow what is needed, the rest we a simply
re-reading the current breaks and making a break decision from that.

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

Well it is hard to say really. But I will say that it is important to
continue to publicly demonstrate progress.
I am sure the current design has the potential to do more than the
current simplistic situation, to me it is a question of how to do it

> 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 hate infinite loops just as much as the everyone else.
I think that it is currently far less prone to the problem and I intend
to continue to ensure it won't happen.

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

The best thing I can say is: understand the issues and start doing it.

I'm not saying that we shouldn't indeed make a complete tree of the
document and decide the best breaks. I just don't think that enforcing
that situation is a good idea when we could layout the first page when
there is a force page break or no keeps.

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

Reply via email to