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.


Reply via email to