XFA Specification
Chapter 7, Layout for Growable Objects
Flowing Layout for Containers
228
The Layout Algorithm
The layout processor is described below and throughout this specification in terms of an algorithm. Note
that, notwithstanding the algorithmic description in this specification, conforming implementations are
not required to follow the same algorithm internally. They are only required to produce the same results
given the same inputs. Similarly, although this specification uses object-oriented terms and concepts,
conforming implementations may be written in any language and use any internal structure, as long as
they produce the same results given the same inputs. The node structure described here is not necessarily
the same structure used by any particular implementation.
The layout processor is content-driven. It makes a single traversal of the content subtree of the Form DOM,
adding nodes to the Layout DOM as it goes until all of the content has been processed (or some other
termination condition is reached). The layout processor keeps track of a current content node and a
current container. The current content node is the node in the Form DOM representing the content
currently being processed. A new layout content node is added to the Layout DOM to represent the
newly-placed content. The current container is the node in the Layout DOM which will be the parent of the
new layout content node.
The starting point in the content is the root subform of the Template DOM. All content is descended from
the root subform. The root subform may also specify the starting point in the hierarchy of containers (the
starting container). If it does not specify a starting point the starting point defaults to the first
contentArea
of the first
pageSet
which is a child of the root subform. The layout processor recursively
copies the nodes from the root subform down to the starting container into the Layout DOM, reproducing
the parent-child relationships.
There is a hierarchy of containers. The outermost container is the
pageSet
, which contains
pageArea
objects.
pageArea
objects contain background material such as a letterhead or watermark, as well as
contentArea
objects.
contentArea
objects contain foreground material, including both boilerplate
and user-supplied data.
contentArea
objects may directly contain draws, areas, fields, subforms, and
subform sets. From this level of the hierarchy down the schema is identical to that defined for the Template
DOM. Subforms and areas may directly contain draws and fields. A layout object of any other type must be
contained in a draw or a field. In addition areas, subforms, and subform sets may contain lower-level areas,
subforms, and/or subform sets nested to any depth.
The layout processor places background ahead of any other content of the same
pageArea
within the
Layout DOM. This gives background objects a position within the Z-order such that overlapping
foreground objects should be drawn on top. However, there is no guarantee that overlapped foreground
and background objects will render properly on all output devices.
The current content node starts at the root of the content subtree of the Form DOM and traverses the
content subtree depth-first and left-to-right (oldest-to-newest). This order is also known as
document
order,
although not all DOMs are ever expressed as XML documents. As each new content node is
encountered it is placed within the current container, unless and until the current container fills up. When
the current container fills up, the Layout DOM is extended by adding nodes as necessary and the layout
processor traverses to a new node to find the new current container. For example, a template contains the
following declarations:
<subform Name="A" layout="position" …>
<!-- root subform -->
<pageSet …>
<pageArea name="X">
<draw name="XBackground" x="1cm" y="22cm" …>
<text …>background text</text>
</draw>
<contentArea name="Y" x="2cm" y="2cm" w="13cm" h="18cm" … />