xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arved Sandstrom <Arved...@chebucto.ns.ca>
Subject Re: RFC: Tentative Ideas for Improvements [Long]
Date Fri, 23 Mar 2001 02:19:44 GMT
At 10:30 PM 3/22/01 +0100, Karen Lease wrote:
>Hi folks,
>The idea of "layout transactions" has a cool sound to it (which doesn't
>keep it from giving Arved a warm fuzzy :-)
>But even though it sounds cool, I think my worry is sort of like Fotis'.
>I'd express it by saying that it feels too local, especially when any
>kind of floatng FOs are involved.

Such an impression would be my fault for being imprecise. What I am really 
trying to say is this: we are all aware that the granularity of our control 
structures maps one-to-one to our FO's; however, we can identify a number of 
situations where a "thing" (a "layout transaction" for want of a better 
word) that maps to sets of FO's provides for a better control wrapper or 
control container.

What a transaction is (i.e. what it wraps) is determined by the problem.

I am also not expecting this mechanism to solve every problem we have. I 
hope it helps out quite a bit. My gut feeling is that something like it is a 
step in the right direction.

>Arved, in one of the examples in your first post, you wrote:
>> The end point is at the end of its layout() - the condition is "are all
>> areas in one context area?" If Yes, we commit, i.e. we set the status of 
>> affected areas to be committed, not pending. If No, we rollback.
>What exactly does it mean for the area to be committed? I don't think it
>can mean that we won't touch it again. Imagine that we are in two column
>layout and that a following area contains a before-float or footnote. If
>we put that on the page, it shortens the main flow area, and that means
>we need to look again at some areas which may already be committed.

My picture of how this would work is that _however_ we do this kind of 
situation, we have to know exactly what our rules and algorithms are before 
we code it up, or it's a mess. If we do it in a more traditional FOP way, 
and have all sorts of FOP classes knowing about the guts of other FOP 
classes, we still have to do this kind of backtracking and re-layout. I 
looked at some of the code we have now, and decided that yours truly does 
not want to add more logic of this sort to any of our layout methods. I 
suspect nobody else does either.

A "transaction" is not a magic bullet for these situations. What it is, 
though, is a wrapper around the situation, pulling the logic for handling 
the situation out of the individual FO's, and hopefully simplifying 
implementation a good deal.

In your example above, yes, absolutely, if the before-float went on that 
page, the main-reference-area would get shortened up. And we would revisit 
FOs that have put their areas into the affected page. In other words, all of 
this, IMO, would be part of a single transaction. Or there would be two 
transactions contained in yet another.

>It's clear that the transaction handlers have to know a lot of things
>about the layout strategy of their children. When I was thinking about
>space-specifiers a while ago, I had the idea of a LayoutManager (or
>several), which implemented various strategies for fitting areas on
>pages. I think there is a kind of bubble-up effect between lower level
>managers and higher level managers. Way back in January (of this year!)
>during an extended keeps discussion, Peter West wrote down some
>interesting ideas along this line, in which he suggested that some kinds
>of layout processes on a page were going along in parallel and vying for
>space (this is an extreme simplification of his post).

Precisely. All due credit where credit is due. I read everything that gets 
posted on this list, and although I can't specifically recall any of it, 
necessarily, months later, I can guarantee that all of it shapes my thinking 
until the whole ball of wax comes together, and I get an idea.

Yes, absolutely, I agree that there is a bubble-up effect. In a primitive 
way we have that now with FO layout() methods, and status codes. But this 
doesn't allow for backtracking or retries, and it is tied to the existing

Your LayoutManager presumably shares many design concepts and goals with the 
"transaction" idea I am flogging.

>This is rather how I see the situation with float placement, keeps and
>breaks and column-balancing.
>Each area has a certain "weight" which it can bring to bear. For
>example, if we layout a block with a before-float in it, that float
>"wants" to be placed on the same page as the anchor area. But it has
>less weight than the anchor itself, ie. if laying out the float causes
>the block to be broken over the page boundary and the anchor area is
>thrown onto the next page, the solution is no good. There is an absolute
>requirement that the float be on the same or a later page as its anchor.
>So if the anchor can't be squeezed onto the page with its float, the
>float will have to be put onto the next page. In the one-column case,
>this is still fairly manageable. It obviously gets worse in the
>multi-column case, since other blocks besides the one containing the
>anchor may need to be revisited. Then we could run into things like a
>block which has keep-together=always being broken over a column boundary
>in order to get the float to fit. So the layout strategist has to know
>how to backup and try again. It also has to recognize impossible
>situations, like things which want to be kept together but which won't
>fit on any page (the famous make pages forever problem).

I think we can capture all of these with rules. As I sort of broke things 
down 2 posts ago, I think that an atomic layout situation (something that is 
amenable to being described by a "transaction", or being handled by a 
LayoutManager) must be describable according to:

(1) start point;
(2) end point;
(3) condition(s)/test(s); and
(4) what is the change mechanism for influencing a different (better) layout 
outcome the next time around? Could be area-based, FO-based, or a hybrid.

I'm currently writing down actual use cases and trying to describe all of the
basic ones with this 4-point "transaction description". I'll add the above 
also. Then I'm going to start combining them, and see how we can act on sets 
of conditions/rules (keep strengths, the "weights" you allude to above, etc. 

>A general remark about the "rollback" idea. I would think we could often
>avoid redoing the inline layout of a block again if we need to change
>the break decision. If the parent reference area still has the same
>inline-progression dimension, we should just be able to shove areas
>(LineAreas, nested BlockAreas) from one BlockArea parent to another. If
>we get into serious layout stategies, this kind of optimization will be
>interesting. Of course there are cases where we can't do this. One is
>where the page designer has been so perverse as to use page-masters with
>different column widths in the same page-sequence. We might also get
>this with intruding side-floats. And if we want to get really
>sophisticated, we could do inline reflow to fix things like not being
>able to hyphenate a word which is broken over a column or a page!

I was thinking more of the general case when I suggested that we would 
re-layout. You are of course correct - there are situations where we could 
transfer areas.

Getting into sophisticated reflow...I was sort of hinting at that as being 
one of the other 2 major strategies that we probably don't want to get into 
in a big way until we get FOP 1.0 out the door, and can re-assess and take a 
breather. What do you think?


Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia

To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

View raw message