StaticContentLM breaks its content?

[Vincent Hennebert <vi...@anyware-tech.com>]

Hi,

Does anyone know why does StaticContentLM implement its own breaker
(StaticContentBreaker) and breaks its content using the
PageBreakingAlgorithm? AFAIK descendants of a static-content element are
not supposed to be broken over several pages.

Thanks,
Vincent


-- 
Vincent Hennebert                            Anyware Technologies
http://people.apache.org/~vhennebert         http://www.anyware-tech.com
Apache FOP Committer                         FOP Development/Consulting

Re: StaticContentLM breaks its content?

[Jeremias Maerki <de...@jeremias-maerki.ch>]

It's right that the descendants of static-content should not be broken,
but using the breaker allows to make use of the stretch/shrink
functionality (min/opt/max stuff) without having to write extra
duplicate code just for static content.

On 05.06.2008 13:27:36 Vincent Hennebert wrote:
> Does anyone know why does StaticContentLM implement its own breaker
> (StaticContentBreaker) and breaks its content using the
> PageBreakingAlgorithm? AFAIK descendants of a static-content element are
> not supposed to be broken over several pages.


Jeremias Maerki

Re: StaticContentLM breaks its content?

[Andreas Delmelle <an...@telenet.be>]

On Jun 5, 2008, at 13:27, Vincent Hennebert wrote:

> Does anyone know why does StaticContentLM implement its own breaker
> (StaticContentBreaker) and breaks its content using the
> PageBreakingAlgorithm? AFAIK descendants of a static-content  
> element are
> not supposed to be broken over several pages.

I can't say for sure, since I did not implement it, but if I were to  
guess...

The main algorithm that is associated to the PageBreaker, serves to  
compute breaks in the flow content. The 'parts' produced there don't  
really correspond to pages, but to body-regions (and footnotes; in  
the future most likely also before- and after-floats). Static- 
contents do not play an active role here. We're only creating a sort  
of sub-pages for the side-regions after reaching each effective page- 
break in the flow. The legal breaks in the static-content itself are  
apparently only computed provisionally. In  
StaticContentBreaker.doPhase3(), we check whether the algorithm  
produced more than one part to see if there is overflow. Following  
that, the computed breaks are removed from the element list.

Reading that again, it does seem a /bit/ weird... Why even bother to  
compute the breaks if we just throw them away afterwards? I may be  
missing something.

The main reasons for which there seems to be a separate Breaker:
- to perform/mimic those parts that are handled by PageBreaker for  
the flow-descendants
- to keep the associated BreakingAlgorithm and its results/state  
completely isolated from what happens in PageBreaker

Note that there is no direct link between PageBreaker and  
StaticContentLayoutManager (apart from inserting one for the footnote- 
separator, but that's a special case). For regular static-contents,  
the creation of the LMs is triggered upon finishing a page.  
(PageSequenceLayoutManager.finishPage())

Note also: even if an identical static-content, without any dynamic  
content --retrieve-marker-- is used for all pages, currently we still  
recreate the LM-tree and redo the layout for each page. This could be  
improved for the most general use-cases IMO by holding a reference to  
the created StaticContentLMs. If we have already used the simple-page- 
master for a preceding page, we could recycle the LMs for its static- 
contents; if there are no retrieve-markers, all we'd really need to  
perform multiple times is add the areas.



Andreas