Processing published leaf boundaries

After the initial release is published, TopLeaf manages the partition content as a set of document leaves. When an unchanged looseleaf document is typeset, each published leaf boundary identifies a leaf break point that prevents the allocation of additional content to the leaf being processed. If a looseleaf document contains leaves that have been changed or manually included, TopLeaf ignores all published leaf boundaries within runs of adjacent changed or included leaves, typesetting the content of each leaf run as a single unit. The published boundary at the end of the run identifies a break point that prevents the allocation of additional content to the leaf run being processed.

When scanned document content spans a published leaf boundary, the leaf inclusion status influences how the content of the leaves is processed. If neither of the leaves sharing the boundary have been changed or included then the position of the boundary within the scanned content will be honored. An exception to this rule may occur if the rendered scanned content of a changed or included leaf overflows into the following leaf — for example, where a leaf boundary follows a hyphenated word or word break character, or is positioned within a split table row.

The composition engine may be required to automatically include a leaf if the adjacent leaf sharing a scanned leaf boundary is changed or included. This action may result in the inclusion of additional leaves in the release if you have not enabled output page comparison.

However, TopLeaf will not honor the position of an existing scanned leaf boundary that is rendered: