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
