Respone below. -----Original Message----- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 19, 2002 5:06 AM To: FOP 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 >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. > 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 children. >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]
