Please find attached some preliminary notes on the implementation of
footnotes.
Peter
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- $Id: xml-parsing.xml,v 1.6 2002-02-15 11:25:24+10 pbw Exp pbw $ -->
<!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd">
<document>
<header>
<title>Implementing footnotes</title>
<authors>
<person name="Peter B. West" email="[EMAIL PROTECTED]"/>
</authors>
</header>
<body>
<!-- one of (anchor s1) -->
<s1 title="Implementing footnotes in FOP">
<p>
Footnotes present difficulties for page layout primarily
because their point of invocation in the flow is different
from their point of appearance in the area tree. All of the
content lines of a footnote may appear on the same page as its
invocation point, all may appear on a following page, or the
lines may be split over a page or pages. (This characteristic
leads to another problem when a footnote overflows the last
page of flow content, but that difficulty will not be
discussed here.) This note considers some aspects of the
implementation of footnotes in a galley-based design.
</p>
<s2 title="The organisation of the galleys">
<s3 title="The layout tree">
<p>
For the purposes of this discussion, I will assume a
<strong>layout tree</strong>, intermediate between the
<em>FO tree</em> and the <em>area tree</em>. The purpose
of such a structure is to allow layout management to test
the viability of proposed layout decisions by enabling
look-ahead in the galleys.
</p>
<note>
It must be stressed that this concept has not been
developed or tested, and may well be redundant as an
actual structure.
</note>
<p>
The layout tree resembles the area tree in basic
structure; under the root wil be a list of
page-viewport-areas, descending through the outer area
structure of the individual pages to the areas generated
by FOs from flows of both kinds. It is below the flow
level that the differences will occur. Areas at this
level will provide attachment points for the galleys to
enable galley pre-processing and look-ahead.
</p>
</s3>
<s3 title="Galley pre-processing">
<p>
As indicated in earlier notes, galleys are sequences of
flow objects sourced from fo:flow and fo:static-content
flows. The galleys themselves are sources of objects for
targets in the area tree. Galley pre-processing involves
the spatial resolution of objects from the flows to the
greatest extent possible without information on the
dimensions of the target area. In terms of inline-areas,
galleys would resolve the dimensions of included images
and process text. Text would be collected into runs with
the same alignment characteristics, resolving block
progession dimension and noting all natural and hyphenated
break points.
</p>
<p>
Once this pre-processing has been achieved, it is
envisaged that a layout manager might make requests to the
galley of its ability to fill an area of a given
inline-progression-dimension. A positive response would
be accompanied by the block-progression-dimension. The
other possibilities are a partial fill, which would also
require b-p-d data, and a failure due to insufficient
i-p-d, in which case the minimum i-p-d requirement would
be returned. Note that decisions about the
actual dimensions of line-areas to be filled can be
deferred until all options have been tested.
</p>
<p>
Apart from information request, higher-level
processes can either make requests of the galleys for
chunks of nominated sizes, or simply attach the galley to
a particular area <em>in the area tree</em> and release
the galley to fill. The galleys must be able to respond to a
sequence of information requests, more or less in the
manner of a reqest iterator, and separately manage the
flushing of objects into the area tree.
</p>
</s3>
<s3 title="Footnotes and galleys">
<p>
In the structure described above, footnotes would be
pre-processed as galleys themselves, but they would remain
attached as subtrees to their points of invocation in the
main text. Allocation to a footnote-reference-area would
only occur in the area tree.
</p>
<p>
When footnotes are introduced, the communication between
galleys and layout manager, as mentioned above, would be
affected. The returned infomation would two b-p-d values:
the primary line-area b-p-d impact and the footnote b-p-d
impact. The distinction is necessary for two reasons; to
alert the layout manager to the first footnote of the
page, and because the footnote b-p-d will always impact
the main-reference-area b-p-d, whereas the primary
inline-area may not, e.g. in the case of multiple
span-areas.
</p>
</s3>
<s3 title="Layout managers in the flow of control">
<note>To be developed.</note>
</s3>
<s3 title="Implications for keeps">
<p>
In the case of footnotes, this sketchy model provides for
very localised look-ahead to provide the information for
page breaks where footnotes are involved. The same model
can probably be extended to deal with keeps. It allows
for look-ahead on keeps to check for available space
before committing areas to a particular page.
</p>
</s3>
</s2>
</s1>
</body>
</document>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
