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]
