You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by "Peter B. West" <pb...@powerup.com.au> on 2003/06/16 18:08:16 UTC
Design notes - 2. LayoutPageSequence
The interesting thing about the layoutPageSequence process/method is the
division of labour between the PageMaker and the PageSequence. In this
view, the processing of the page-sequence has a life independent of the
layout of individual pages.
Referring back to my earlier notes on layout transactions, consider the
situation in which the attempt to layout a line-area from some block is
rejected because the receiving page is full. Assume, for the purposes
of the argument, that this occurs with a nested set of FOs. One page
fills, and another must be provided, while a nest of FOs has pending
output. This situation determines the essential logic of the processing.
The layoutPageSequence action starts a PageMaker, possibly as a thread
of its own, and then proceeds with the page-sequence processing, pulling
elements from the buffer as required. These begin with the
static-contents, which, harking back to another earlier message, are
simply buffered for later processing and possible merging with buffered
maker subtree events.
When these are out of the way, the action gets the flow, and starts to
pull the content blocks of the flow. As each top-level block is found,
the contents of that block are recursively laid out. More detail of
this process in the next diagram. Note that at this stage, nothing is
known about the containing page.
Eventually the top-level block layout action demands page space. This
is where the min/max requirements will make themselves known. Such
demands from a top-level block within a flow are passed to the
PageMaker. When the first of these demands, or the first demand after a
page has been filled, is encountered, no page exists to receive the
block contents. The PageMaker consults the LayoutMasterSet.pageFactory
for a new page, and constructs the page and region viewport and
reference-areas. These are then available as receptacles for the
contents of the top-level blocks.
The current and subsequent top-level blocks then negotiate space
requirements, acting as go-between to the PageMaker and its own
descendants.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html