Embedded leaf boundaries

An embedded boundary occurs when a leaf boundary falls within scanned or transformed document content (for example, in a split table row, a split column footnote, when reformatted as a custom table or within the context of a custom marker) . The leaves adjacent to an embedded boundary are always composed as a single unit, irrespective of whether the content of either leaf is changed or manually included.

In the following example, an <invoice> block contains two items:

<invoice>
  <item>
    <code>SL6500A</code>
    <quantity>20</quantity>
    <unit-price>14.50</unit-price>
    <total-price>290.00</total-price>
  </item>
   <item>
    <code>SL7600N</code>
    <quantity>8</quantity>
    <unit-price>6.25</unit-price>
    <total-price>50.00</total-price>
  </item>
</invoice>

The components of each <item> are scanned, allocated to user variables, and formatted as a custom table row by the </item> end tag mapping. The entire table is emitted by the enclosing </invoice> mapping.

When rendered, the custom table splits across the leaf boundary between leaves 17 and 19:

but when published, the leaf boundary is positioned after the elements containing the scanned document content:

In subsequent releases, if leaf 17 or leaf 19 is changed or manually included, TopLeaf will force an automatic leaf inclusion of the adjacent leaf, until such time as the custom table content allocated to leaf 17 is no longer rendered within leaf 19.

In many cases, the output produced for leaves that have been automatically included will be unchanged from the previously published output. You can use output page comparison to minimise the effect of automatic leaf inclusions on the size of the update pack.