Does this take into account the keep values that have the range: 0..9, 
always. It is not possible to simply say that a given group of keeps 
should stay together, you need to find the lowest keep value closest to 
the optimum spacing position and within minimum.

On 2002.04.16 05:24 Peter B. West wrote:
> Soothed Foperators,
> I have been looking for a while, like everybody else, at keeps.  I was 
> looking for a way to unify the processing of keeps and breaks at the 
> layout level.  Breaks are easy enough; just create column-break and 
> page-break pseudo-area and insert into the galley as a sibling of the 
> affected object's area subtree.  Once that's done, look-ahead and 
> re-layout operate on the same stream of galley objects.  However, keeps 
> didn't fit.
> It occurred to me that, conceptually, the keeps can all be expressed as 
> a new 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.
> 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 naturally tree-structured flow of processing.  Such problems 
> are endemic in page layout.
> 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.  I have yet to examine inline 
> relationships or the problem of changes in block-progression-direction, 
> but just looking at the simple block stacking cases, you get a diagram 
> like the attached PNG.  In order to track the relationships through the 
> tree, I think you need four sets of links.  The basic links are:
> Leading edge to leading edge of first normal child.
> Trailing edge to leading edge of next normal sibling.
> Trailing edge to trailing edge of parent
> 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.
> 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.
> I will be looking at what happens with changes of 
> block-progression-direction and the related structures for inline keeps. 
> How does this gel with what other people are doing with keeps?
> Peter

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to