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.


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 

(1) normal areas (xsl-normal), side-floats (xsl-side-float), and all anchors 

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


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

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

.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 

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 started, the footnote body takes 
priority on subsequent pages over other content.

*** Introduction of Side-Floats ***

A side-float becomes a child of the nearest ancestor reference area (I still 
need to figure out what the hell the spec means by "reference area chain", 
so this may change). This will usually (but not always) be a column area 
within a span area within a main-reference-area. The location of the anchor 
will determine the current ("nearest") ancestor reference area.

Karen and I discussed this, and I believe that all efforts would be made to 
have the side-float be placed with its before edge starting level with the 
before edge of the line area containing the anchor.

The effect of a side-float will be to apply an intrusion adjustment on one 
or more IFS's, starting at an internal offset into that IFS.

I'm not going to say more about side-floats at the moment - there is some 
inconsistency, ambiguity and contradiction in the language of the spec, and 
I need to clarify stuff on the W3C XSL list.

*** Forward References ***

Mainly, a page-number-citation referencing a later page.

General approach is no mystery...insert an inline of some fixed length, and 
when the page number becomes available, update the content. There will be no 

I am inclined to explore the possibility of using listeners to dynamically 
update the content. Suggestions welcome.


As I said, this is Part 1 of the Page Layout part of prelimary design 
concepts. Part 2 will treat tables, mostly, and talk about the other 4 
regions on the page.

Part 2 will also talk about the approach required to handle 
reference-orientation and writing-mode.

Arved Sandstrom

Fairly Senior Software Type
e-plicity (
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia

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

Reply via email to