Responses Below.

-----Original Message-----
From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 20, 2002 3:38 AM
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

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

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

Reply via email to