Responses Below. -----Original Message----- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 3:38 AM To: FOP Subject: RE: Getting breaks: revisited
>> 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. << Well, let's take the idea that we were starting at square one with respect to LM development. One possibly strategy would be to make a pass over all of the objects to be laid out, visiting each one and, while not laying it out, gathering information about what explicit constraints each one is under. Armed with this information, a layout system could create a plan for reconciling all constraints, even dropping constraints if they were in conflict. This is essentially the same thing as the LayoutPlan concept mentioned by other developers. The first "pass" isn't really a layout pass but a sort of scouting out issues relevant to the layout process. I could see how this sort of "scouting ahead" could help resolve even some of the issues you mentioned, such as footnotes throwing monkey wrenches in the system. Maybe this is what you mean when you say "the first pass reads the fo and sorts out most of the layout," and we just have our wires crossed. >> 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. >> The problem, as I see it, is that those breaks aren't always trustworthy. My stripped down FO document in bug #8778 had the same problem in HEAD that it does in maintenance (at least, it did a few weeks ago). A problem is in the cases where the LM offers breaks where it thinks they should best be put, but choosing the breaks in that fashion prevents the content from actually getting laid out anywhere. A few weeks ago, you expressed disbelief that this was happening, but I know what I was seeing and I know what I did to terminate the loop, and I offered to show you the experiment I'd run at my desk. Maybe things have been shored up since then, since that was weeks ago, in which case my point is moot. >>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 cleanly.<< Right...I'm agreeing wholeheartedly there, but I'm asking about some issues that I don't see being addressed in the layout system in HEAD. You seem very steadfast in the belief that the design for layout in HEAD, as it is, is all that we need, and so I'm curious as to how you think it will address issues like the one I'm bringing up. If it won't, then what I am proposing is that the layout system as it is in HEAD is a critical tool in a much larger process of layout and that more layout tools are needed to work with it. >>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.<< The very simple loop-causing document I put in bug #8778 seems to me to be a fundamental demonstration of how constraints in conflict create loops. A simple case like this one shows nearly identical behavior between maintenance and HEAD. Though it's much easier in HEAD to code an LM to spot the characteristic "lack of progress" and try to break out of the cycle, I don't see how this can be used to address the real issue- the fact that two disparite constraints contradict each other. >>The best thing I can say is: understand the issues and start doing it.<< I may be green, but I did spot some of this a couple weeks ago, and it went mostly unnoticed. While writing this email, I downloaded another CVS snapshot and the super-simple test document from bug #8778, which is probably the simplest of all the i-loop cases, and ran it again...it's the same thing I saw when I last brought this up. >>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.<< Well, maybe there's a balance to be struck, but my test document on bug #8778 has no keeps and, despite the "space-before" being enough to nudge content into spilling off the page and triggering a break before the block, is incredibly simple, yet the LM system is skewered by the contradicting complaints. I guess what I'm asking is what thoughts you have on solving this issue in a general fashion, since I can definitely see that, if a simple case of conflicting constraints like bug #8778 causes havoc, that larger and more indirect combinations of constraints can pile up and do the same thing. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
