7
Layout for Growable Objects
Various layout objects, including fields and subforms, can be made growable. A growable object starts off
at a certain size but can stretch to accommodate more content. It is possible to impose a maximum size
limit on a growable object, or it may be infinitely elastic.
Placing growable objects upon fixed-size pages presents a problem. Where should the objects be placed?
What should happen if a growable object does not fit in the region where it is to be placed? This chapter
discusses how these problems are addressed by an XFA layout processor.
Background and Goals
When an XFA processing application produces a document, the physical arrangement of the document
may change depending on the supplied data. For example, the supplied text may overflow the boundaries
of the associated region of the page into another region. This specification codifies the rules which govern
the physical placement of displayable objects upon a page or display screen and the actions which are
taken when a displayable entity does not fit in the space allocated for it. It does
not
deal with rendering of
the laid-out page on the display device, which is handled downstream in a renderer. Rendering is outside
the scope of XFA.
If these rules are followed any XFA layout processor, given the same Template DOM, Form DOM, locale
settings and typefaces, will produce the same layout as any other XFA layout processor. This means that all
glyphs and other displayed objects will be positioned at the same places and on the same pages. It does
not guarantee identical appearance of the finished documents because there may be differences in
rendering, for example, between a monochrome printer and a color printer. However, it is expected that
on comparable display devices, with the same fonts and page sizes, the alignment of printed entities will
be reproduced to within one pixel. This degree of reproducibility is important for some uses of electronic
forms, notably when using forms whose appearance is prescribed by law. On the other hand, forms do not
require the refined text processing that is used in publishing – kerning and so on. It is more important that
the placement of text be fast (because it may be done by an application running on a multitasking server)
and, above all, robust.
Some XFA applications do not include a layout processor. This may even be true of client applications that
present a form for interactive filling and update. Instead the form may have been already laid out and
rendered by an upstream process. In that case the client may (but is not required to) rely upon the
pre-rendered image of the form rather than performing layout and rendering for itself. However this is
only feasible with a subset of forms known as
static
forms. See
“Static Forms Versus Dynamic Forms” on
page 259
chapter applies to every form when it passes through the layout process, whether the form is static or
dynamic.
The reader of this specification will learn how the XFA layout process proceeds, its inputs and outputs, its
limitations and options. This information is valuable to implementors who wish to create an
XFA-compliant layout processor or generate XFA-compliant templates, and to users of electronic forms
who want to understand them in greater depth.
217