Design - Document level and bottom-up layout

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

Fopdevs,

I seem to recall Victor talking about Session and Document levels in one 
of his postings, but I cannot find it.

In respect of the Document level, it seesm to me that there are three 
separate subtrees under fo:root - layout-master-set, declarations, and 
the sequence of page-sequences.  layout-master-set and declarations are 
Document-level constants, which provide context for the mapping of flows 
into pages.  I have been thinking, without drawing any conclusions, 
about the appropriate control structures/objects to map this 
relationship, which is why my memory was jogged about Victor's (?) posting.

My main concern in these cogitations has been the possibility of doing 
bottom-up layout.  I have been intrigued by Jeffrey Kingston's Lout 
design document ever since it was drawn to my attention over two years 
ago on this list.
http://snark.ptc.spbu.ru/~uwe/lout/design.pdf

It includes this comment on page 14:
<quote>
One must calculate that 1.9 inches ... is available to the paragraph, 
and break it accordingly; Basser Lout does this in two stages. In the 
first, upward-moving stage, widths are calculated ... which assume that 
available space is infinite. If the upward movement reaches a WIDE node 
... and the calculated width exceeds that allowed, a second, 
downward-moving stage is initiated which attempts to reduce the width by 
finding and breaking paragraphs.
</quote>

It is only recently that I have begun to see the rationale for this, and 
how it might be applied to FOP. (The mind moves in mysterious and 
exceeding slow ways.)

Layout is constrained along two axes.  In the first place, it is 
constrained by the size of the medium; the page, in our case. In the 
second, it is constrained by the size of the atoms which are being 
placed in the page space; the individual characters and other objects 
like images.  (Bear with me in this simplification.)  Interposed between 
the page constraints and the atoms of the flow are a series of 
containers.  For the most part, these containers have at least an 
IPDimension and an implied limit effectively imposed by the page 
constraints.  In difficult cases, e.g. auto table layout, they do not. 
I believe that we need to approach the design as a solution of the most 
difficult cases, and implement the easier cases as optimisations.

The flow hierarchy defines a (generally nested) series of containers for 
the atoms.  This sequence is derived as the flow (which is a hierarchy) 
is descended.  When tha atoms are encountered, the process reverses.

In the worst case, an fo:block, e.g., acting as the immediate parent of 
the atoms, lays itself out assuming "infinite" width (which may be 
defined as the page width or height).  That is, it generates a tentative 
single line-area.  On the way, it notes all of its possible break 
positions, perhaps as two sets, with and without hypenation.  It is then 
in a position to demand page space.  This demand will be expressed as a 
range [min, max IPDim, min, max BPDim (not sure about BPD)].  All of 
this is done on "optimum" assumptions.  The demand percolates back up 
through the container hierarchy until it reaches an absolute constraint. 
  In the case of auto table layout, this demand will make its way back 
to the table definition level.  The table will then make demands of its 
own on its own container.

At some point a (possibly tentative) conclusion is reached about the 
available space, and this decision is relayed back down the hierarchy to 
the immediate parent of the atoms.  The information previously obtained 
about break possibilities is then used to feed the requested area back 
to the parent.

One of the virtues of this approach is that it automates a process which 
seemed to me to be awkward.  When a page fills, it will generally occur 
at a point where some atomic composition is in process, in the depths of 
  a nest of containers.  It has always seemed to me awkward to set up a 
new nest of incomplete containers for the new page.  With bottom-up 
layout, this will occur at the next request for page space from the 
atomic level.  This request percolates up from through the existing 
containers to the page level, and any adjustments to the container 
constraints (from a change in the master, e.g.) will flow back down.

It also has implications for inline containers.  Inline containers can 
be seen as being in an analogous relation to line-areas as block-areas 
are to regions.  This would imply what seems to be a divergent view from 
the latest expressed by the editors, but I think the matter requires 
some further clarification anyway.

If an fo:inline, e.g., is viewed as one of the subcontainers of a 
line-area, whose descendants are feeding page space requests back 
through it to the containing block-area, then the exhaustion of a 
line-area while the fo:inline is still active is like the exhaustion of 
a region while an fo:block is still active.   A request from below for 
more line-area space is passed up to the inline's parent block, which 
generates and provides a fresh line-area for use by the inline and its 
descendants.  I'll have to run that one by the editors.

Peter
-- 
Peter B. West  http://www.powerup.com.au/~pbwest/resume.html


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

Re: Design - Document level and bottom-up layout

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

J.Pietschmann wrote:
> Peter B. West wrote:
> 
>> My main concern in these cogitations has been the possibility of doing 
>> bottom-up layout.

...

> That's basically how layout works in HEAD. Each layout manager
> basically works as follows:
> - set up known constraints and fetch the first child layout manager
> - loop
>   -  ask the active child layout manager for the next break, passing
>      known constraints
>   -  reconcile with constraints and check whether it would make
>      a break for this layout manager, if so return it
>   -  break loop if constraints are violated
> In a second step, the layout manager is asked for areas up to the
> passed break.
> Rebalancing (due to footnotes, column spans, all kinds of floats
> and perhaps forward page number references) complicates this, but
> table auto layout should fit nicely.

The approach I sketched out in the alt.design notes on footnotes
<http://xml.apache.org/fop/design/alt.design/footnotes.html> performs 
dynamic column balancing and footnote placement in order to minimise the 
complications.  Page overflow should be detected on the addition of a 
single line-area that causes the overflow.

> The constraints allow for optimization of the most common case where
> the dimension relevant for break computation is fixed in advance. In
> the code it's the layoutContext.
-- 
Peter B. West  http://www.powerup.com.au/~pbwest/resume.html


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

Re: Design - Document level and bottom-up layout

["J.Pietschmann" <j3...@yahoo.de>]

Peter B. West wrote:
> My main concern in these cogitations has been the possibility of doing 
> bottom-up layout.
...
> <quote>
> One must calculate that 1.9 inches ... is available to the paragraph, 
> and break it accordingly; Basser Lout does this in two stages. In the 
> first, upward-moving stage, widths are calculated ... which assume that 
> available space is infinite. If the upward movement reaches a WIDE node 
> ... and the calculated width exceeds that allowed, a second, 
> downward-moving stage is initiated which attempts to reduce the width by 
> finding and breaking paragraphs.
> </quote>
> 
That's basically how layout works in HEAD. Each layout manager
basically works as follows:
- set up known constraints and fetch the first child layout manager
- loop
   -  ask the active child layout manager for the next break, passing
      known constraints
   -  reconcile with constraints and check whether it would make
      a break for this layout manager, if so return it
   -  break loop if constraints are violated
In a second step, the layout manager is asked for areas up to the
passed break.
Rebalancing (due to footnotes, column spans, all kinds of floats
and perhaps forward page number references) complicates this, but
table auto layout should fit nicely.
The constraints allow for optimization of the most common case where
the dimension relevant for break computation is fixed in advance. In
the code it's the layoutContext.

J.Pietschmann



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

RE: Design - Document level and bottom-up layout

[Victor Mote <vi...@outfitr.com>]

Peter B. West wrote:

> I seem to recall Victor talking about Session and Document levels in one 
> of his postings, but I cannot find it.

It is at
http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization
in a section entitled "Startup Concepts Proposal".

Victor Mote

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