pbwest 02/04/28 06:27:44 Added: docs/design/alt.design keeps.xml spaces.xml Log: Adding documents to ALT DESIGN Revision Changes Path 1.1 xml-fop/docs/design/alt.design/keeps.xml Index: keeps.xml =================================================================== <?xml version="1.0" encoding="ISO-8859-1"?> <!-- $Id: keeps.xml,v 1.1 2002/04/28 13:27:44 pbwest Exp $ --> <!-- <!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd"> --> <document> <header> <title>Keeps and breaks</title> <authors> <person name="Peter B. West" email="[EMAIL PROTECTED]"/> </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> 1.1 xml-fop/docs/design/alt.design/spaces.xml Index: spaces.xml =================================================================== <?xml version="1.0" encoding="ISO-8859-1"?> <!-- $Id: spaces.xml,v 1.1 2002/04/28 13:27:44 pbwest Exp $ --> <!-- <!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd"> --> <document> <header> <title>Keeps and space-specifiers</title> <authors> <person name="Peter B. West" email="[EMAIL PROTECTED]"/> </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>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]