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 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
re-formatting.
I am inclined to explore the possibility of using listeners to dynamically
update the content. Suggestions welcome.
OTHER CONSIDERATIONS
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.
Regards,
Arved Sandstrom
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
