--- /dev/null
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!-- $Id$ -->
+<!--
+<!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd">
+-->
+
+<document>
+ <header>
+ <title>Keeps and breaks</title>
+ <authors>
+ <person name="Peter B. West" email="pbwest@powerup.com.au"/>
+ </authors>
+ </header>
+ <body>
+ <!-- one of (anchor s1) -->
+ <s1 title="Keeps and breaks in layout galleys">
+ <p>
+ The <link href= "galleys.html" >layout galleys</link> and the
+ <link href= "galleys.html#layout-tree" >layout tree</link>
+ which is their context have been discussed elsewhere. Here we
+ discuss a possible method of implementing keeps and breaks
+ within the context of layout galleys and the layout tree.
+ </p>
+ <s2 title="Breaks">
+ <p>
+ Breaks may be handled by inserting a column- or page-break
+ pseudo-object into the galley stream. For break-before, the
+ object would be inserted before the area in which the flow
+ object, to which the property is attached, is leading. If
+ the flow object is leading in no ancestor context, the
+ pseudo-object is inserted before the object itself.
+ Corresponding considerations apply for break-after.
+ Selection of the position for these objects will be further
+ examined in the discussion on keeps.
+ </p>
+ </s2>
+ <s2 title="Keeps">
+ <p>
+ Conceptually, all keeps can be represented by a
+ keep-together pseudo-area. The keep-together property
+ itself is expressed during layout by wrapping all of the
+ generated areas in a keep-together area. Keep-with-previous
+ on formatting object A becomes a keep-together area spanning
+ the first non-blank normal area leaf node, L, generated by A
+ or its offspring, and the last non-blank normal area leaf
+ node preceding L in the area tree. Likewise, keep-with-next
+ on formatting object A becomes a keep-together area spanning
+ the last non-blank normal area leaf node, L, generated by A
+ or its offspring, and the first non-blank normal area leaf
+ node following L in the area tree.
+ <br/>TODO REWORK THIS for block vs inline
+ </p>
+ <p>
+ The obvious problem with this arrangement is that the
+ keep-together area violate the hierarachical arrangement of
+ the layout tree. They form a concurrent structure focussed
+ on the leaf nodes. This seems to be the essential problem
+ of handling keep-with-(previous/next); that it cuts across
+ the otherwise tree-structured flow of processing. Such
+ problems are endemic in page layout.
+ </p>
+ <p>
+ In any case, it seems that the relationships between areas
+ that are of interest in keep processing need some form of
+ direct expression, parallel to the layout tree itself.
+ Restricting ourselves too block-level elements, and looking
+ only at the simple block stacking cases, we get a diagram
+ like the attached PNG. In order to track the relationships
+ through the tree, we need four sets of links.
+ </p>
+ <p>
+ <strong>Figure 1</strong>
+ </p>
+ <anchor id="Figure1"/>
+ <figure src="block-stacking.png" alt="Simple block-stacking
+ diagram"/>
+ <p>
+ The three basic links are:
+ </p>
+ <ul>
+ <!-- one of (dl sl ul ol li) -->
+ <li>Leading edge to leading edge of first normal child.</li>
+ <li>Trailing edge to leading edge of next normal
+ sibling.</li>
+ <li>Trailing edge to trailing edge of parent.</li>
+ </ul>
+ <p>
+ Superimposed on the basic links are bridging links which
+ span adjacent sets of links. These spanning links are the
+ tree violators, and give direct access to the areas which
+ are of interest in keep processing. They could be
+ implemented as double-linked lists, either within the layout
+ tree nodes or as separate structures. Gaps in the spanning
+ links are joined by simply reproducing the single links, as
+ in the diagram. The whole layout tree for a page is
+ effectively threaded in order of interest, as far as keeps
+ are concerned.
+ </p>
+ <p>
+ The bonus of this structure is that it looks like a superset
+ of the stacking constraints. It gives direct access to all
+ sets of adjacent edges and sets of edges whose space
+ specifiers need to be resolved. Fences can be easily enough
+ detected during the process of space resolution.
+ </p>
+ </s2>
+ </s1>
+ </body>
+</document>
--- /dev/null
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!-- $Id$ -->
+<!--
+<!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd">
+-->
+
+<document>
+ <header>
+ <title>Keeps and space-specifiers</title>
+ <authors>
+ <person name="Peter B. West" email="pbwest@powerup.com.au"/>
+ </authors>
+ </header>
+ <body>
+ <!-- one of (anchor s1) -->
+ <s1 title="Keeps and space-specifiers in layout galleys">
+ <p>
+ The <link href= "galleys.html" >layout galleys</link> and the
+ <link href= "galleys.html#layout-tree" >layout tree</link>
+ which is the context of this discussion have been discussed
+ elsewhere. A <link href="keeps.html">previous document</link>
+ discussed data structures which might facilitate the lining of
+ blocks necessary to implement keeps. Here we discuss the
+ similarities between the keep data structures and those
+ required to implement space-specifier resolution.
+ </p>
+ <s2 title="Space-specifiers">
+ <note>
+ <strong>4.3 Spaces and Conditionality</strong>
+ ... Space-specifiers occurring in sequence may interact with
+ each other. The constraint imposed by a sequence of
+ space-specifiers is computed by calculating for each
+ space-specifier its associated resolved space-specifier in
+ accordance with their conditionality and precedence.
+ </note>
+ <note>
+ 4.2.5 Stacking Constraints ... The intention of the
+ definitions is to identify areas at any level of the tree
+ which have only space between them.
+ </note>
+ <p>
+ The quotations above are pivotal to understanding the
+ complex discussion of spaces with which they are associated,
+ all of which exists to enable the resolution of adjacent
+ <space>s. It may be helpful to think of <em>stacking
+ constraints</em> as <em><space>s interaction</em> or
+ <em><space>s stacking interaction</em>.
+ </p>
+ </s2>
+ <s2 title="Block stacking constraints">
+ <p>
+ In the discussion of block stacking constraints in Section
+ 4.2.5, the notion of <em>fence</em> is introduced. For
+ block stacking constraints, a fence is defined as either a
+ reference-area boundary or a non-zero padding or border
+ specification. Fences, however, do not come into play
+ when determining the constraint between siblings. (See
+ <link href="#Figure1">Figure 1</link>.)
+ </p>
+ <p><strong>Figure 1</strong></p><anchor id="Figure1"/>
+ <figure src="block-stacking-constraints.png"
+ alt="block-stacking-constraints.png"/>
+ <note>
+ Figure 1 assumes a block-progression-direction of top to
+ bottom.
+ </note>
+ <p>
+ In <link href="#Figure1">Diagram a)</link>, block A has
+ non-zero padding and borders, in addition to non-zero
+ spaces. Note, however, that the space-after of A is
+ adjacent to the space-before of block P, so borders and
+ padding on these siblings have no impact on the interaction
+ of their <space>s. The stacking constraint A,P is
+ indicated by the red rectangle enclosing the space-after of
+ A and the space-before of P.
+ </p>
+ <p>
+ In <link href="#Figure1">Diagram b)</link>, block B is the
+ first block child of P. The stacking constraint A,P is as
+ before; the stacking constraint P,B is the space-before of
+ B, as indicated by the enclosing magenta rectangle. In this
+ case, however, the non-zero border of P prevents the
+ interaction of the A,P and P,B stacking constraints. There
+ is a <em>fence-before</em> P. The fence is notional; it has
+ no precise location, as the diagram may lead one to believe.
+ </p>
+ <p>
+ In <link href="#Figure1">Diagram c)</link>, because of the
+ zero-width borders and padding on block P, the fence-before
+ P is not present, and the adjacent <space>s of blocks
+ A, P and B are free to interact. In this case, the stacking
+ constraints A,P and P,B are as before, but now there is an
+ additional stacking constraint A,B, represented by the light
+ brown rectangle enclosing the other two stacking
+ constraints.
+ </p>
+ <p>
+ The other form of fence occurs when the parent block is a
+ reference area. Diagram b) of <link href="#Figure2">Figure
+ 2</link> illustrates this situation. Block C is a
+ reference-area, involving a 180 degree change of
+ block-progression-direction (BPD). In the diagram, the
+ inner edge of block C represents the content rectangle, with
+ its changed BPD. The thicker outer edge represents the
+ outer boundary of the padding, border and spaces of C.
+ </p>
+ <p>
+ While not every reference-area will change the
+ inline-progression-direction (IPD) and BPD of an area, no
+ attempt is made to discriminate these cases. A
+ reference-area always a fence. The fence comes into play in
+ analogous circumstances to non-zero borders or padding.
+ Space resolution between a reference area and its siblings
+ is not affected.
+ </p>
+ <p>
+ In the case of <link href="#Figure2">Diagram b)</link>,
+ these are block stacking constraints B,C and C,A. Within
+ the reference-area, bock stacing constraints C,D and E,C are
+ unaffected. However, the fence prevents block stacking
+ constraints such as B,E or D,A. When there is a change of
+ BPD, as <link href="#Figure2">Diagram b)</link> makes
+ visually obvious, it is difficult to imagine which blocks
+ would have such a constraint, and what the ordering of the
+ constraint would be.
+ </p>
+ <p><strong>Figure 2</strong></p>
+ <anchor id="Figure2"/>
+ <figure src="block-stacking-keeps.png"
+ alt="block-stacking-keeps.png"/>
+ </s2>
+ <s2 title="Keep relationships between blocks">
+ <p>
+ As complicated as space-specifiers become when
+ reference-areas are involved, the keep relationships as
+ described in the <link
+ href="keeps.html#Figure1">keeps</link> document, are
+ unchanged. This is also illustrated in <link
+ href="#Figure2">Figure 2</link>. Diagram b) shows the
+ relative placement of blocks in the rendered output when a
+ 180 degree change of BPD occurs, with blocks D and E
+ stacking in the reverse direction to blocks B and C.
+ Diagram c) shows what happens when the page is too short to
+ accommodate the last block. D is still laid out, but E is
+ deferred to the next page.
+ </p>
+ <p>
+ Note that this rendering reality is expressed directly in
+ the area (and layout) tree view. Consequently, any keep
+ relationships expressed as links threading through the
+ layout tree will not need to be modified to account for
+ reference-area boundaries, as is the case with similar
+ space-specifier edge links. E.g., a keep-with-next
+ condition on block B can be resolved along the path of these
+ links (B->C->D) into a direct relationship of B->D,
+ irrespective of the reference-area boundary.
+ </p>
+ <p>
+ While the same relationships obviously hold when a reference
+ area induces no change of BPD, the situation for BPD changes
+ perpendicular to the parent's BPD may not be so clear. In
+ general, it probably does not make much sense to impose keep
+ conditions across such a boundary, but there seems to be
+ nothing preventing such conditions. They can be dealt with
+ in the same way, i.e., the next leaf block linked in area
+ tree order must be the next laid out. If a keep condition
+ is in place, an attempt must be made to meet it. A number
+ of unusual considerations would apply, e.g. the minimum
+ inline-progression-dimension of the first leaf block within
+ the reference-area as compared to the minimum IPD of
+ subsequent blocks, but <em>prima facie</em>, the essential
+ logic of the keeps links remains.
+ </p>
+ </s2>
+ </s1>
+ </body>
+</document>
projects / xmlgraphics-fop.git / commitdiff