Keeps and space specifiers

["Peter B. West" <pb...@powerup.com.au>]

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

Re: Keeps and space specifiers

["Peter B. West" <pb...@powerup.com.au>]

Keiron,

That would be just a matter of associating a value with the keep.  The 
main thing about the approach I outlined is to provide a structure which 
allows keeps (and stacking constraints) to be expressed more readily.

Incidentally, speaking of min/opt/max values, my feeling is that, in a 
look-ahead model, the initial layout should use optimum values only. 
 Then, only if some layout infelicity or contradiction occurs, the 
layout manager, wherever that sits in the process hierarchy, will start 
probing the galleys for possible layouts in the minimum ior maximum 
directions.  Which to try first will probably be heuristically 
determined, based on the type of layout errors which can occur.  One of 
the variables here will be the "strength" of keeps, but, as far as I can 
tell, the weakest keep will only be discarded after the options implicit 
in min/opt/max have been exhausted.  I haven't given any thought to any 
of this, though.

Peter

Keiron Liddle wrote:

>
> 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.
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: Keeps and space specifiers

[Keiron Liddle <ke...@aftexsw.com>]

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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org