Here are some initial thoughts on another aspect of redesign. This is
complementary to Karen Lease's thoughts from one week ago (20th June).
This is not a formal design document. The intention would be to turn this
into one, though, within a couple of weeks, that will sit in CVS.
HIGH-LEVEL PICTURE
We can picture 3 cooperating subsystems: one is oriented toward pages, one
to blocks, and one to inlines. Karen described the operation of the latter -
this fundamentally reduces to providing an Inline FlowSet (IFS)
corresponding to each "raw" block. A "raw" block maps to an original FO that
generates block-level areas (not necessarily normal).
The block-oriented and inline-oriented subsystems are processes, whereas the
page-oriented subsystem becomes rather more of an "on-demand" page-provider
than it is now. We assume for the purposes of this discussion that there
exists a "page factory" that produces the "next" page as required, with
suitable request flags.
It is the function of the inline-building process to provision a number of
queues:
(1) normal areas (xsl-normal), side-floats (xsl-side-float), and all anchors
(xsl-anchor);
(2) before-floats (xsl-before-float);
(3) footnote bodies (xsl-footnote).
Absolutely-positioned areas (xsl-absolute and xsl-fixed, pertaining to
absolutely-positioned block-containers) need not be maintained as a queue -
they are taken out of the normal flow and do not affect layout of later
stuff (we do of course need to maintain a pointer to the page that they must
be on, as required by 7.4.1, Restrictions).
All areas will possess complete traits (returned-by, generated-by,
is-reference-area, for example, plus parent ID) as required by the spec,
both directly and indirectly derived.
It is the function of the page-layout (block-oriented) process to consume
material in these queues, and to layout pages.
PAGE LAYOUT
*** Basic Operation ***
Def'n: "basic" means no keeps, no floats, no footnotes, no forward
references. I will also not discuss tables until Part 2 of this note (to
appear in a few days).
The page layout engine (PLE) pops areas from the normal queue. Each area
uniquely maps to an IPD. In the most basic situation, the basic IPD is
restricted to 2 possibilities on any given page-master, corresponding to
span='all' or span='none'. The PLE instructs each IFS to line-break itself,
given appropriate constraints (generally, the base IPD and the available BPD).
Breaks are unambiguous and simple. They terminate the current page. The
"page factory" will be provided with sufficient information to react
appropriately (e.g. possible production of blank pages).
The PLE will make use of an auxiliary Space-Specifier-Resolution module as
required.
*** Introduction of Keeps ***
.within-line keeps affect line-breaking, and are of no concern to the PLE.
In addition, all keeps that are negated by breaks are removed or suitably
modified.
.within-column and .within-page keeps consist of keep-with-next (KWN),
keep-with-previous (KWP) and keep-together (KT). A KWP on area N+1 will be
translated into a KWN on area N. All KT conditions will be translated into
KWN conditions (except for the last area affected by a KT). Superimposed KWN
conditions that result will be refined into one KWN, that has the highest
strength. [ Note: please poke holes in this, if you think of any ]
This process will provide the PLE with "KWN chains" that make it much easier
to compute actual page-breaks.
I will talk more about this; this will be treated in detail in design. I
invite lots of comment and participation. :-)
*** Introduction of Before-Floats and Footnotes ***
Discussion below implicitly assumes proper treatment of
xsl-before-float-separator and xsl-footnote-separator. That is, when
calculations of BPD are made, the static-contents, if any, must be included.
-- Before-Floats --
Before floats are placed at the top of the page containing the anchor, or on
a subsequent page, and must be properly ordered in their class.
As anchor areas are encountered in the normal queue, the decision-making is
two-fold:
1) does the before-float "fit" on the current page, and if so, does the
anchor get displaced to the next page? [ "fit" means an assessment based on
heuristics similar to fractional coverage rules for floats as found in
LaTeX; I anticipate exposing the capability to adjust these heuristics
through a strategy object that gets loaded by user configuration data ]; and
2) does retaining an otherwise acceptable before-float on the current page
represent an optimal choice in light of any keep conditions on text?
Decision may be made to punt the float to the next page.
-- Footnotes --
I believe that very similar design choices can be made here as for
before-floats. The main difference is that extra weight will be placed on
starting the footnote body on the same page as the anchor (that is, the last
area returned by the inline), and that once star
