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: Page and Column Breaks
Date Thu, 28 Dec 2000 02:18:32 GMT
At 10:19 AM 12/28/00 +1000, Keiron Liddle wrote:

>Arved Sandstrom wrote:
>> I took a looksee. What I would suggest is, the infrastructure is already
set up
>> in BodyAreaContainer.java. This area represents the region-body
reference area,
>> and is responsible for maintaining 3 child areas - one for the main
>> area, and one each for optional before-floats and footnotes.
>I have the footnote reference area under control.

Glad to hear it. :-) Please don't hesitate to make overall improvements to 
BodyAreaContainer if you see possibilities - the BodyAreaContainer is there 
to handle 3 reference areas, but at this early stage of the game it 
obviously is targeted only at the main-reference-area, and is likely wanting 
when it comes to footnotes and before-floats.

>> You can access the BodyAreaContainer (BAC) via the Page - there is a
>> blockArea.setPage(area.getPage()) inside the layout() method for
>> for example. The method getFootnoteReferenceArea() in BodyAreaContainer
>> the AreaContainer for footnotes. Once this is obtained, I would suggest
>> out the footnote separator (if present) and the footnote-body into the
>> footnoteRefArea AreaContainer, getting that resulting height, and seeing
if the
>> remaining height available to the main-reference-area can be borrowed
from. The
>> BAC method getRemainingHeight() may even work already to give you that
>> :-) In fact, to make this work, you will need to have the available height
>> already assigned to the footnoteReferenceArea as its maxHeight, and then
it's a
>> question of looking at the content height after layout. The maxHeight of
>> footnoteRefArea would need to be trimmed before installing it into the BAC.
>The problem with this is that for all of the elements the new area is 
>only placed in the area it is doing the layout to after it has placed 
>whatever it can in the new area. The best we can do is get the available 
>space after completing the current line.

Right. One possibility is to add a FOOTNOTE_INTERRUPT code to Status, that 
propagates back up, allows necessary footnote processing to be done, and 
then we can resume where we left off. Just the glimmering of an idea.

>> If the footnote reference area will fit, it can be installed at
>> footnoteRefAreaYPosition += footnoteRefArea.getContentHeight(), and that
>> space subtracted from the maxHeight of the main-reference-area. The
>> footnoteRefAreaYPosition is initially set to be at the bottom of the
>> region-reference-area, reflecting a zero-height footnoteRefArea.
>Yes, it also needs to subtract the amount from the areas already added 
>to the main-reference-area (ie. the columns) and areas that are being 
>created and haven't been added yet.

The relevant method here for the current (being created) area is 
getTotalContentHeight() in SpanArea; this will total up all content height 
in column areas. As an example, let's say we have one span area already laid 
out, say SpanArea A, with height h1. We come up on a footnote partway 
through doing 3-column SpanArea B, and getTotalContentHeight() on SpanAreaB 
returns h2. If the maxHeight of the main-reference-area is H, then we are OK 
if H - h1 - h2/3 > footnoteRefAreaHeight.

One caveat: there are some issues with spaces during this calculation, I 
think. This is one reason my balancing doesn't work so well yet. But I think 
this errs on the side of safety at present.

The other issue: for multicolumn, the odds are 50-50 for 2-column, 67% for 
3-column, etc etc, that we will have to re-layout (not balance, just 
re-layout) the current span area when _its_ max height is decreased. So we 
need to consider the best way to do this.

>I'll create some examples/tests and put them in cvs to try against.

I'll be all over them to provide fast feedback. :-)

One major bonus - once footnotes are tackled, then before-floats pretty much 
are taken care of, too.

Regards, Arved

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

View raw message