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 Tue, 20 Mar 2001 11:53:34 GMT
At 10:14 AM 3/20/01 +0100, Fotis Jannidis wrote:
>Don't we need a second pass for some informations anyway or at 
>least some book-keeping for them (p.e. fo:retrieve-marker)? But is 
>the idea to preprocess the FO tree (in portions of page-sequences) 
>heading in that direction anyway? 

Yes, I don't think an explicit second pass is ruled out by the discussion 
here. I don't think fo:marker and fo:retrieve-marker cause us major problems 
at this stage, not for this kind of layout problem, because the content goes 
into fo:static-content, not fo:flow.

>How do you define the start and end point of areas which should 
>come under one transaction handler? [Rereading your letter, I saw 
>that you asked the question yourself] I am thinking of the balancing 
>of footnote text over two pages where the number of affected blocks 
>changes with different layouts, that is in the second attempt more 
>blocks could be affected? If you have footnotes on every page - as 
>is usual in the texts I have to handle - then you would have to 
>handle overlapping transaction subtrees, don't you?

Nested transactions are going to happen; we need to decide if overlaps make 
sense and how to handle them - do they get combined?

My gut feeling is that the areas covered by the transaction handler are 
those areas generated by the FO's that are children of the transaction. To 
use your example concerning footnotes, I don't think that more blocks are 
affected, per se, not in the sense we both mean.

In my 2 examples, in one the transaction changed FO conditions (imposed a 
"break-before") and in the other the transaction changed the layout 
environment (shortens the span area for column balancing). If we choose to 
allow footnote body placement into following pages, I think we cover that by 
changing the layout environment - i.e. adjusting the footnote-reference-area 
sizes. So the other fo:block's on that subsequent page are _indirectly_ 
affected - they have less main-reference-area to lay out into - but they are 
not directly included in the transaction.

I think it's OK, even desirable, for the transaction (handlers) to possess 
knowledge of the layout strategy of their FO children. E.g. a transaction 
handler for a complicated footnote situation knows what our strategy is for 
placing footnote body content, and this is how it knows to influence the 
layout geometry to cause an optimum result. A concrete implementation of a 
Transaction _should_ know about stuff like this - it is collecting that 
knowledge so as to keep the code of its children as clean as possible.

We need to do up some design notes, I think, that detail our layout 
strategies for various situations. I can document the column-balancing one, 
and also keeps. I think it is best to have this fixed on paper before we code.
In the case of footnotes, we need to anticipate all possible situations
and write down the solutions, first, I believe, otherwise we're in
trouble. :-)

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