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