Submitted By: "Peter B. West" <pbwest@powerup.com.au> git-svn-id: https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk@194720 13f79535-47bb-0310-9956-ffa450edef68tags/fop-0_20_4-doc
<?xml version="1.0" encoding="ISO-8859-1"?> | <?xml version="1.0" encoding="ISO-8859-1"?> | ||||
<!-- $Id$ --> | <!-- $Id$ --> | ||||
<!-- | <!-- | ||||
<!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd"> | |||||
<!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd"> | |||||
--> | --> | ||||
<document> | <document> | ||||
<header> | <header> | ||||
when no value has been assigned. | when no value has been assigned. | ||||
</p> | </p> | ||||
<s2 title="The history problem"> | <s2 title="The history problem"> | ||||
</s2> | |||||
<p> | <p> | ||||
The difficulty and expense of handling properties comes from | The difficulty and expense of handling properties comes from | ||||
this univeral inheritance possibility. The list of properties | this univeral inheritance possibility. The list of properties | ||||
specified on an ancestor of this element, and the initial | specified on an ancestor of this element, and the initial | ||||
value of the property. | value of the property. | ||||
</p> | </p> | ||||
</s2> | |||||
<s2 title="Data requirement and structure"> | <s2 title="Data requirement and structure"> | ||||
<p> | <p> | ||||
This determines the minimum set of properties and associated | This determines the minimum set of properties and associated |
<separator/> | <separator/> | ||||
<external href="../index.html" label="NEW DESIGN" /> | <external href="../index.html" label="NEW DESIGN" /> | ||||
<separator/> | <separator/> | ||||
<page id="index" label="alt.properties" source="alt.properties.xml"/> | |||||
<page id="index" label="co-routines" source="coroutines.xml"/> | |||||
<page id="galleys" label="galleys" source="galleys.xml"/> | |||||
<page id="footnotes" label="footnotes" source="footnotes.xml"/> | |||||
<separator/> | |||||
<page id="alt.properties" label="alt.properties" source="alt.properties.xml"/> | |||||
<page id="classes-overview" label="Classes overview" source="classes-overview.xml"/> | <page id="classes-overview" label="Classes overview" source="classes-overview.xml"/> | ||||
<page id="properties-classes" label="Properties classes" source="properties-classes.xml"/> | <page id="properties-classes" label="Properties classes" source="properties-classes.xml"/> | ||||
<page id="Properties" label="Properties" source="Properties.png.xml"/> | <page id="Properties" label="Properties" source="Properties.png.xml"/> | ||||
<page id="xml-parsing" label="XML parsing" source="xml-parsing.xml"/> | <page id="xml-parsing" label="XML parsing" source="xml-parsing.xml"/> | ||||
<separator/> | <separator/> | ||||
<page id="property-parsing" label="Property parsing" source="propertyExpressions.xml"/> | <page id="property-parsing" label="Property parsing" source="propertyExpressions.xml"/> | ||||
<separator/> | |||||
<page id="compound-properties" label="Compound properties" source="compound-properties.xml"/> | |||||
<page id="traits" label="Traits" source="traits.xml"/> | |||||
</book> | </book> |
<?xml version="1.0" encoding="ISO-8859-1"?> | |||||
<!-- $Id$ --> | |||||
<!-- | |||||
<!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd"> | |||||
--> | |||||
<document> | |||||
<header> | |||||
<title>Compound properties</title> | |||||
<authors> | |||||
<person name="Peter B. West" email="pbwest@powerup.com.au"/> | |||||
</authors> | |||||
</header> | |||||
<body> | |||||
<s1 title="Compound properties in XSLFO"> | |||||
<table> | |||||
<tr> | |||||
<th>Property type</th> | |||||
<th>Section</th> | |||||
<th>Inherited</th> | |||||
<th>'inherit'</th> | |||||
</tr> | |||||
<tr> | |||||
<th><length-range></th> | |||||
</tr> | |||||
<tr> | |||||
<th>minimum</th> | |||||
</tr> | |||||
<tr> | |||||
<th>optimum</th> | |||||
</tr> | |||||
<tr> | |||||
<th>maximum</th> | |||||
</tr> | |||||
<tr> | |||||
<td>block-progression-dimension</td> | |||||
<td>7.14.1</td> | |||||
<td>no</td> | |||||
<td>yes</td> | |||||
</tr> | |||||
<tr> | |||||
<td>inline-progression-dimension</td> | |||||
<td>7.14.5</td> | |||||
<td>no</td> | |||||
<td>yes</td> | |||||
</tr> | |||||
<tr> | |||||
<td>leader-length</td> | |||||
<td>7.21.4</td> | |||||
<td>yes</td> | |||||
<td>yes</td> | |||||
</tr> | |||||
<tr> | |||||
<th><length-conditional></th> | |||||
</tr> | |||||
<tr> | |||||
<th>length</th> | |||||
</tr> | |||||
<tr> | |||||
<th>conditionality</th> | |||||
</tr> | |||||
<tr> | |||||
<td>border-after-width</td> | |||||
<td>7.7.12</td> | |||||
<td>no</td> | |||||
<td>yes</td> | |||||
</tr> | |||||
<tr> | |||||
<td>border-before-width</td> | |||||
<td>7.7.9</td> | |||||
<td>no</td> | |||||
<td>yes</td> | |||||
</tr> | |||||
<tr> | |||||
<td>border-end-width</td> | |||||
<td>7.7.18</td> | |||||
<td>no</td> | |||||
<td>yes</td> | |||||
</tr> | |||||
<tr> | |||||
<td>border-start-width</td> | |||||
<td>7.7.15</td> | |||||
<td>no</td> | |||||
<td>yes</td> | |||||
</tr> | |||||
<tr> | |||||
<td>padding-after</td> | |||||
<td>7.7.32</td> | |||||
<td>no</td> | |||||
<td>yes</td> | |||||
</tr> | |||||
<tr> | |||||
<td>padding-before</td> | |||||
<td>7.7.31</td> | |||||
<td>no</td> | |||||
<td>yes</td> | |||||
</tr> | |||||
<tr> | |||||
<td>padding-end</td> | |||||
<td>7.7.34</td> | |||||
<td>no</td> | |||||
<td>yes</td> | |||||
</tr> | |||||
<tr> | |||||
<td>padding-start</td> | |||||
<td>7.7.33</td> | |||||
<td>no</td> | |||||
<td>yes</td> | |||||
</tr> | |||||
<tr> | |||||
<th><length-bp-ip-direction></th> | |||||
</tr> | |||||
<tr> | |||||
<th>block-progression-direction</th> | |||||
</tr> | |||||
<tr> | |||||
<th>inline-progression-direction</th> | |||||
</tr> | |||||
<tr> | |||||
<td>border-separation</td> | |||||
<td>7.26.5</td> | |||||
<td>yes</td> | |||||
<td>yes</td> | |||||
</tr> | |||||
<tr> | |||||
<th><space></th> | |||||
</tr> | |||||
<tr> | |||||
<th>minimum</th> | |||||
</tr> | |||||
<tr> | |||||
<th>optimum</th> | |||||
</tr> | |||||
<tr> | |||||
<th>maximum</th> | |||||
</tr> | |||||
<tr> | |||||
<th>precedence</th> | |||||
</tr> | |||||
<tr> | |||||
<th>conditionality</th> | |||||
</tr> | |||||
<tr> | |||||
<td>letter-spacing</td> | |||||
<td>7.16.2</td> | |||||
<td>yes</td> | |||||
<td>yes</td> | |||||
</tr> | |||||
<tr> | |||||
<td>line-height</td> | |||||
<td>7.15.4</td> | |||||
<td>yes</td> | |||||
<td>yes</td> | |||||
</tr> | |||||
<tr> | |||||
<td>space-after</td> | |||||
<td>7.10.6</td> | |||||
<td>no</td> | |||||
<td>yes</td> | |||||
</tr> | |||||
<tr> | |||||
<td>space-before</td> | |||||
<td>7.10.5</td> | |||||
<td>no</td> | |||||
<td>yes</td> | |||||
</tr> | |||||
<tr> | |||||
<td>space-end</td> | |||||
<td>7.11.1</td> | |||||
<td>no</td> | |||||
<td>yes</td> | |||||
</tr> | |||||
<tr> | |||||
<td>space-start</td> | |||||
<td>7.11.2</td> | |||||
<td>no</td> | |||||
<td>yes</td> | |||||
</tr> | |||||
<tr> | |||||
<td>word-spacing</td> | |||||
<td>7.16.8</td> | |||||
<td>yes</td> | |||||
<td>yes</td> | |||||
</tr> | |||||
<tr> | |||||
<th><keep></th> | |||||
</tr> | |||||
<tr> | |||||
<th>within-line</th> | |||||
</tr> | |||||
<tr> | |||||
<th>within-column</th> | |||||
</tr> | |||||
<tr> | |||||
<th>within-page</th> | |||||
</tr> | |||||
<tr> | |||||
<td>keep-together</td> | |||||
<td>7.19.3</td> | |||||
<td>yes</td> | |||||
<td>yes</td> | |||||
</tr> | |||||
<tr> | |||||
<td>keep-with-next</td> | |||||
<td>7.19.4</td> | |||||
<td>no</td> | |||||
<td>yes</td> | |||||
</tr> | |||||
<tr> | |||||
<td>keep-with-previous</td> | |||||
<td>7.19.5</td> | |||||
<td>no</td> | |||||
<td>yes</td> | |||||
</tr> | |||||
</table> | |||||
</s1> | |||||
</body> | |||||
</document> |
<?xml version="1.0" encoding="ISO-8859-1"?> | |||||
<!-- $Id$ --> | |||||
<!-- | |||||
<!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd"> | |||||
--> | |||||
<document> | |||||
<header> | |||||
<title>Implementing co-routines</title> | |||||
<authors> | |||||
<person name="Peter B. West" email="pbwest@powerup.com.au"/> | |||||
</authors> | |||||
</header> | |||||
<body> | |||||
<!-- one of (anchor s1) --> | |||||
<s1 title="Implementing Co-routines in FOP"> | |||||
<p> | |||||
All general page layout systems have to solve the same | |||||
fundamental problem: expressing a flow of text with its own | |||||
natural structure as a series of pages corresponding to the | |||||
physical and logical structure of the output medium. This | |||||
simple description disguises many complexities. Version 1.0 | |||||
of the Recommendation, in Section 3, <em>Introduction to | |||||
Formatting </em>, includes the following comments. | |||||
</p> | |||||
<note> | |||||
[Formatting] comprises several steps, some of which depend on | |||||
others in a non-sequential way.<br/> ...and...<br/> | |||||
[R]efinement is not necessarily a straightforward, sequential | |||||
procedure, but may involve look-ahead, back-tracking, or | |||||
control-splicing with other processes in the formatter. | |||||
</note> | |||||
<p>Section 3.1, <em>Conceptual Procedure</em>, includes:</p> | |||||
<note> | |||||
The procedure works by processing formatting objects. Each | |||||
object, while being processed, may initiate processing in | |||||
other objects. While the objects are hierarchically | |||||
structured, the processing is not; processing of a given | |||||
object is rather like a co-routine which may pass control to | |||||
other processes, but pick up again later where it left off. | |||||
</note> | |||||
<s2 title="Application of co-routines"> | |||||
<p> | |||||
If one looks only at the flow side of the equation, it's | |||||
difficult to see what the problem might be. The ordering of | |||||
the elements of the flow is preserved in the area tree, and | |||||
where elements are in an hierarchical relationship in the | |||||
flow, they will generally be in an hierarchical relationship | |||||
in the area tree. In such circumstances, the recursive | |||||
processing of the flow seems quite natural. | |||||
</p> | |||||
<p> | |||||
The problem becomes more obvious when one thinks about the | |||||
imposition of an unrelated page structure over the | |||||
hierarchical structure of the document content. Take, e.g., | |||||
the processing of a nested flow structure which, at a certain | |||||
point, is scanning text and generating line-areas, nested | |||||
within other block areas and possibly other line areas. The | |||||
page fills in the middle of this process. Processing at the | |||||
lowest level in the tree must now suspend, immediately | |||||
following the production of the line-area which filled the | |||||
page. This same event, however, must also trigger the closing | |||||
and flushing to the area tree of every open area of which the last | |||||
line-area was a descendant. | |||||
</p> | |||||
<p> | |||||
Once all of these areas have been closed, some dormant process | |||||
or processes must wake up, flush the area sub-tree | |||||
representing the page, and open a new page sub-tree in the | |||||
area tree. Then the whole nested structure of flow objects | |||||
and area production must be re-activated, at the point in | |||||
processing at which the areas of the previous page were | |||||
finalised, but with the new page environment. The most | |||||
natural way of expressing the temporal relationship of these | |||||
processes is by means of co-routines. | |||||
</p> | |||||
<p> | |||||
Normal sub-routines (methods) display a hierarchical | |||||
relationship where process A suspends on invoking process B, | |||||
which on termination returns control to A which resumes from | |||||
the point of suspension. Co-routines instead have a parallel | |||||
relationship. Process A suspends on invoking process B, but | |||||
process B also suspends on returning control to process A. To | |||||
process B, this return of control appears to be an invocation | |||||
of process A. When process A subsequently invokes B and | |||||
suspends, B behaves as though its previous invocation of A has | |||||
returned, and it resumes from the point of that invocation. | |||||
So control bounces between the two, each one resuming where it | |||||
left off.<br/><br/> | |||||
<strong>Figure 1</strong> | |||||
</p> | |||||
<figure src="coroutines.png" alt="Co-routine diagram"/> | |||||
<p> | |||||
For example, think of a page-production method working on a | |||||
complex page-sequence-master. | |||||
</p> | |||||
<source> | |||||
void makePages(...) { | |||||
... | |||||
while (pageSequence.hasNext()) { | |||||
... | |||||
page = generateNextPage(...); | |||||
boolean over = flow.fillPage(page); | |||||
if (over) return; | |||||
} | |||||
} | |||||
</source> | |||||
<p> | |||||
The <code>fillPage()</code> method, when it fills a page, will | |||||
have unfinished business with the flow, which it will want to | |||||
resume at the next call; hence co-routines. One way to | |||||
implement them in Java is by threads synchronised on some | |||||
common argument-passing object. | |||||
</p> | |||||
</s2> | |||||
</s1> | |||||
</body> | |||||
</document> |
<?xml version="1.0" encoding="ISO-8859-1"?> | |||||
<!-- $Id$ --> | |||||
<!-- | |||||
<!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd"> | |||||
--> | |||||
<document> | |||||
<header> | |||||
<title>Implementing footnotes</title> | |||||
<authors> | |||||
<person name="Peter B. West" email="pbwest@powerup.com.au"/> | |||||
</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="Footnotes and galleys"> | |||||
<p> | |||||
In the structure described in the <link href= | |||||
"../galleys.html" >introduction to FOP galleys</link>, | |||||
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 resolution | |||||
to Area nodes. | |||||
</p> | |||||
<p> | |||||
When footnotes are introduced, the communication between | |||||
galleys and layout manager, as mentioned <link href= | |||||
"../galleys.html#pre-processing" >above</link>, would be | |||||
affected. The returned information 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> | |||||
</s2> | |||||
<s2 title="Multiple columns and footnotes"> | |||||
<note> | |||||
A possible method for multi-column layout and balancing | |||||
with footnotes, using a galley-based approach. | |||||
</note> | |||||
<p> | |||||
This note assumes a galley, as discussed <link href= | |||||
"../galleys.html" >elsewhere</link>, flowing text with | |||||
footnotes and possibly other blocks into a possibly | |||||
multi-column area. The logic of flowing into multiple | |||||
columns is trivially applied to a single column. The galley | |||||
is manipulated within the context of the <em>layout | |||||
tree</em>. | |||||
</p> | |||||
<p> | |||||
Associated with the galley are two sets of data. | |||||
One contains the maps of all "natural" break-points and | |||||
the of all hyphenation break-points. This set is | |||||
constructed at the time of construction of the galley and | |||||
is a constant for a given galley. The second contains | |||||
dynamic data which represents one possible attempt to lay | |||||
out the galley. There may be multiple sets of such data | |||||
to reflect varying attempts. The data of this set are, | |||||
essentially, representations of line-areas, with the supporting | |||||
information necessary to determine these line-areas. | |||||
</p> | |||||
<p> | |||||
The line-area data includes the boundaries within the | |||||
galley of each line-area, the boundaries of each column | |||||
and the boundaries of the "page", or main area. When a | |||||
line-area boundary occurs at a hyphenation point, a | |||||
"virtual hyphen" is assumed and accounted for in the | |||||
i-p-d. As mentioned, individual footnote galleys will | |||||
hang from the parent galley. The associated data of the | |||||
footnote galleys is similar: a once-only break-points map, | |||||
and one or more line-area maps. No column boundaries are | |||||
required, but a page boundary is required at the end of | |||||
the last footnote or where a footnote breaks across a page | |||||
boundary. | |||||
</p> | |||||
<p> | |||||
A number of b-p-d values are also maintained. For each | |||||
line-area, the b-p-d, the main area b-p-d increment, the | |||||
footnote b-p-d increment and the footnote's page-related | |||||
b-p-d increment are required. The main-area b-p-d | |||||
increments for any particular line-area are dependent on | |||||
the column position of the line-area. Total b-p-d's are | |||||
also kept: total footnote b-p-d, total main area b-p-d, | |||||
and totals for each column.<br/><br/> | |||||
<strong>Figure 1</strong> Columns before first footnote. | |||||
</p> | |||||
<figure src="initial-column-values.png" alt="Columns before | |||||
first footnote"/> | |||||
</s2> | |||||
<s2 title="Balancing columns"> | |||||
<p> | |||||
<strong>Figure 2</strong> Adding a line area with first | |||||
footnote. | |||||
</p> | |||||
<figure src="line-area-5.png" | |||||
alt="Columns after adding first footnote"/> | |||||
<p> | |||||
Columns are balanced dynamically in the galley preliminary | |||||
layout. While the galley retains its basic linear | |||||
structure, the accompanying data structures accomplish | |||||
column distribution and balancing. As each line-area is | |||||
added, the columns are re-balanced. <strong>N.B.</strong> | |||||
This re-balancing involves only some of the dynamic data | |||||
associated with the participating galley(s). The data | |||||
structures associating breakpoints with the beginning and | |||||
end of individual line areas does not change in | |||||
re-balancing; only the association of line-area with column, | |||||
and, possibly, the various impact values for each line-area. | |||||
<br/><br/> | |||||
<strong>Figure 3</strong> Adding a line area with next | |||||
footnote. | |||||
</p> | |||||
<figure src="line-area-6.png" | |||||
alt="Columns after adding next footnote"/> | |||||
</s2> | |||||
<s2 title="Layout managers in the flow of control"> | |||||
<note>To be developed.</note> | |||||
</s2> | |||||
</s1> | |||||
</body> | |||||
</document> |
<?xml version="1.0" encoding="ISO-8859-1"?> | |||||
<!-- $Id$ --> | |||||
<!-- | |||||
<!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd"> | |||||
--> | |||||
<document> | |||||
<header> | |||||
<title>Galleys</title> | |||||
<authors> | |||||
<person name="Peter B. West" email="pbwest@powerup.com.au"/> | |||||
</authors> | |||||
</header> | |||||
<body> | |||||
<!-- one of (anchor s1) --> | |||||
<s1 title="Layout galleys in FOP"> | |||||
<s2 title="Galleys in Lout"> | |||||
<p> | |||||
Jeffrey H. Kingston, in <link href = | |||||
"http://snark.niif.spb.su/~uwe/lout/design.pdf" ><em>The | |||||
Design and Implementation of the Lout Document Formatting | |||||
Language</em> Section 5</link>, describes the | |||||
<strong>galley</strong> abstraction which he implemented in | |||||
<em>Lout</em>. A document to be formatted is a stream of | |||||
text and symbols, some of which are <strong>receptive | |||||
symbols</strong>. The output file is the first receptive | |||||
symbol; the formatting document is the first galley. The | |||||
archetypical example of a receptive symbol is | |||||
<strong>@FootPlace</strong> and its corresponding galley | |||||
definition, <strong>@FootNote</strong>. | |||||
</p> | |||||
<p> | |||||
Each galley should be thought of as a concurrent process, and | |||||
each is associated with a semaphore (or synchronisation | |||||
object.) Galleys are free to "promote" components into | |||||
receptive targets as long as</p> | |||||
<ul> | |||||
<li> | |||||
an appropriate target has been encountered in the file, | |||||
</li> | |||||
<li> | |||||
the component being promoted contains no unresolved galley | |||||
targets itself, and | |||||
</li> | |||||
<li> | |||||
there is sufficient room for the galley component at the | |||||
target. | |||||
</li> | |||||
</ul> | |||||
<p> | |||||
If these conditions are not met, the galley blocks on its | |||||
semaphore. When conditions change so that further progress | |||||
may be possible, the semaphore is signalled. Note that the | |||||
galleys are a hierarchy, and that the processing and | |||||
promotion of galley contents happens <em>bottom-up</em>. | |||||
</p> | |||||
</s2> | |||||
<s2 title="Some features of galleys"> | |||||
<p> | |||||
It is essential to note that galleys are self-managing; they | |||||
are effectively layout <em>bots</em> which require only a | |||||
receptive area. If a galley fills a receptive area (say, at | |||||
the completion of a page), the galley will wait on its | |||||
semaphore, and will remain stalled until a new receptive | |||||
area is uncovered in the continued processing (say, as the | |||||
filled page is flushed to output and a new empty page is | |||||
generated.) | |||||
</p> | |||||
<p> | |||||
Difficulties with this approach become evident when there | |||||
are mutual dependencies between receptive areas which | |||||
require negotiation between the respective galleys, and, in | |||||
some cases, arbitrary deadlock breaking when there is no | |||||
clear-cut resolution to conflicting demands. Footnote | |||||
processing and side floats are examples. A thornier example | |||||
is table column layout in <em>auto</em> mode, where the | |||||
column widths are determined by the contents. In | |||||
implementing galleys in FOP, these difficulties must be | |||||
taken into account, and some solutions proposed. | |||||
</p> | |||||
<p> | |||||
Galleys model the whole of the process of creating the final | |||||
formatted output; the document as a whole is regarded as a | |||||
galley which flushes in to the output file. | |||||
</p> | |||||
</s2> | |||||
<s2 title="The layout tree"> | |||||
<anchor id="layout-tree"/> | |||||
<p> | |||||
This proposal for implementing galleys in FOP makes use of a | |||||
<strong>layout tree</strong>. As with the <link href= | |||||
"../layout.html" >layout managers</link><em></em> already | |||||
proposed, the layout tree acts as a bridge between the <link | |||||
href= "../fotree.html" >FO Tree</link> and the <link href= | |||||
"../areatree.html" >Area Tree</link>. If the elements of | |||||
the FO Tree are FO nodes, and the elements of the Area Tree | |||||
are Area nodes, representing areas to be drawn on the output | |||||
medium, the elements of the layout tree are <strong>galley | |||||
nodes</strong> and <strong>area tree fragments</strong>. | |||||
The area tree fragments are the final stages of the | |||||
resolution of the galleys; the output of the galleys will be | |||||
inserted directly into the Area Tree. The tree structure | |||||
makes it clear that the whole of the formatting process in | |||||
FOP, under this model, is a hierarchical series of galleys. | |||||
The dynamic data comes from fo:flow and fo:static-content, | |||||
and the higher-level receptive areas are derived from the | |||||
<em>layout-master-set</em>. | |||||
</p> | |||||
</s2> | |||||
<s2 title="Processing galleys"> | |||||
<p> | |||||
Galleys are processed in two basic processing environments: | |||||
</p> | |||||
<s3 title="Inline- and block-progression dimensions known"> | |||||
<p> | |||||
The galley at set-up is provided with both an | |||||
<em>inline-progression-dimension</em> (<em>i-p-d</em>) and | |||||
a <em>block-progression-dimension</em> (<em>b-p-d</em>). | |||||
In this case, no further intervention is necessary to lay | |||||
out the galley. The galley has the possibility of laying | |||||
itself out, creating all necessary area nodes. This does | |||||
not preclude the possibility that some children of this | |||||
galley will not be able to be so directly laid out, and | |||||
will fall into the second category. | |||||
</p> | |||||
<p> | |||||
While the option of "automatic" layout exists, to use | |||||
such a method would relinquish the possibility of | |||||
monitoring the results of such layout and performing | |||||
fine-tuning. | |||||
</p> | |||||
</s3> | |||||
<s3 title="Inline- ior block-progression-dimensions unknown"> | |||||
<p> | |||||
The galley cannot immediately be provided with an i-p-d | |||||
ior a b-p-d. This will occur in some of the difficult | |||||
cases mentioned earlier. In these cases, the parent | |||||
galley acts as a layout manager, similar to the sense used | |||||
in <link href= "../layout.html" >another | |||||
discussion</link>. The children, lacking full receptive | |||||
area dimensions, will proceed with galley pre-processing, | |||||
a procedure which will, of necessity, be followed | |||||
recursively by all of its children down to the atomic | |||||
elements of the galley. These atomic elements are the | |||||
individual <em>fo:character</em> nodes and images of fixed | |||||
dimensions. | |||||
</p> | |||||
</s3> | |||||
</s2> | |||||
<s2 title="Galley pre-processing"> | |||||
<anchor id="pre-processing"/> | |||||
<p> | |||||
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. | |||||
Line-areas have a block progression dimension which is | |||||
determined by their contents. To achieve full generality in | |||||
layouts of indeterminate dimensions, the contents of | |||||
line-areas should be laid out as though their inline | |||||
progression dimension were limited only by their content. | |||||
In terms of inline-areas, galleys would process text and | |||||
resolve the dimensions of included images. Text would be | |||||
collected into runs with the same alignment | |||||
characteristics. In the process, all possible "natural" and | |||||
hyphenation break-points can be determined. Where a | |||||
line-area contains mixed fonts or embedded images, the b-p-d | |||||
of the individual line-areas which are eventually stacked | |||||
will, in general, depend on the line break points, but the | |||||
advantage of this approach is that such actual selections | |||||
can be backed out and new break points selected with a | |||||
minimum of re-calculation. This can potentially occur | |||||
whenever a first attempt at page layout is backed out. | |||||
<br/><br/> | |||||
<strong>Figure 1</strong> | |||||
</p> | |||||
<figure src="galley-preprocessing.png" alt="Galley | |||||
pre-processing diagram"/> | |||||
<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> | |||||
The other primary form of information provided by a | |||||
pre-processed galley is its minimum and maximum i-p-d, so | |||||
that decisions can be made by the parent on the spacing of | |||||
table columns. Apart from information requests, | |||||
higher-level processes can either make requests of the | |||||
galleys for chunks of nominated sizes, or simply provide the | |||||
galley with an i-p-d and b-p-d, which will trigger the | |||||
flushing of the galley components into Area nodes. Until | |||||
they have flushed, the galleys must be able to respond to a | |||||
sequence of information requests, more or less in the manner | |||||
of a request iterator, and separately manage the flushing of | |||||
objects into the area tree. The purpose of the "request | |||||
iterator" would be to support "incremental" information | |||||
requests like <em>getNextBreakPosition</em>. | |||||
</p> | |||||
</s2> | |||||
</s1> | |||||
</body> | |||||
</document> |
<?xml version="1.0" encoding="ISO-8859-1"?> | |||||
<!-- $Id$ --> | |||||
<!-- | |||||
<!DOCTYPE document SYSTEM "file:///home/pbw/src/xml-fop/docs/xml-docs/dtd/document-v10.dtd"> | |||||
--> | |||||
<document> | |||||
<header> | |||||
<title>Traits</title> | |||||
<authors> | |||||
<person name="Peter B. West" email="pbwest@powerup.com.au"/> | |||||
</authors> | |||||
</header> | |||||
<body> | |||||
<s1 title="Traits"> | |||||
<table> | |||||
<tr> | |||||
<th>Trait</th> | |||||
<th>Applies to</th> | |||||
<th>Refs</th> | |||||
<th>Derived from</th> | |||||
</tr> | |||||
<tr> | |||||
<th>Common Traits</th> | |||||
</tr> | |||||
<tr> | |||||
<td>block-progression-direction</td> | |||||
<td>All areas</td> | |||||
<td> | |||||
<link href= | |||||
"file:///home/pbw/doc/web/xsl/spec/slice4.html#area-common" | |||||
>4.2.2 Common Traits</link> | |||||
</td> | |||||
<td> | |||||
<link href= | |||||
"file:///home/pbw/doc/web/xsl/spec/slice7.html#reference-orientation" | |||||
>7.27.7 reference-orientation</link> | |||||
</td> | |||||
</tr> | |||||
<tr> | |||||
<th colspan="2"/> | |||||
<td> | |||||
<link href= | |||||
"file:///home/pbw/doc/web/xsl/spec/slice7.html#writing-mode" | |||||
>7.27.7 writing-mode</link> | |||||
</td> | |||||
</tr> | |||||
<tr> | |||||
<td>inline-progression-direction</td> | |||||
<td>All areas</td> | |||||
<td> | |||||
<link href= | |||||
"file:///home/pbw/doc/web/xsl/spec/slice4.html#area-common" | |||||
>4.2.2 Common Traits</link> | |||||
</td> | |||||
<td> | |||||
<link href= | |||||
"file:///home/pbw/doc/web/xsl/spec/slice7.html#reference-orientation" | |||||
>7.27.7 reference-orientation</link> | |||||
</td> | |||||
</tr> | |||||
<tr> | |||||
<th colspan="2"/> | |||||
<td> | |||||
<link href= | |||||
"file:///home/pbw/doc/web/xsl/spec/slice7.html#writing-mode" | |||||
>7.27.7 writing-mode</link> | |||||
</td> | |||||
</tr> | |||||
<tr> | |||||
<td>shift-direction</td> | |||||
<td>Inline areas</td> | |||||
</tr> | |||||
<tr> | |||||
<td>glyph-orientation</td> | |||||
<td></td> | |||||
</tr> | |||||
<tr> | |||||
<td>is-reference-area</td> | |||||
<td>All areas</td> | |||||
<td> | |||||
<link href= | |||||
"file:///home/pbw/doc/web/xsl/spec/slice5.html#section-N6691-Non-property-Based-Trait-Generation" | |||||
>5.6 Non-property Based Trait Generation</link> | |||||
</td> | |||||
<td>Set "true" on:</td> | |||||
</tr> | |||||
<tr> | |||||
<th colspan="3"/> | |||||
<td>simple-page-master</td> | |||||
</tr> | |||||
<tr> | |||||
<th colspan="3"/> | |||||
<td>title</td> | |||||
</tr> | |||||
<tr> | |||||
<th colspan="3"/> | |||||
<td>region-body</td> | |||||
</tr> | |||||
<tr> | |||||
<th colspan="3"/> | |||||
<td>region-before</td> | |||||
</tr> | |||||
<tr> | |||||
<th colspan="3"/> | |||||
<td>region-after</td> | |||||
</tr> | |||||
<tr> | |||||
<th colspan="3"/> | |||||
<td>region-start</td> | |||||
</tr> | |||||
<tr> | |||||
<th colspan="3"/> | |||||
<td>region-end</td> | |||||
</tr> | |||||
<tr> | |||||
<th colspan="3"/> | |||||
<td>block-container</td> | |||||
</tr> | |||||
<tr> | |||||
<th colspan="3"/> | |||||
<td>inline-container</td> | |||||
</tr> | |||||
<tr> | |||||
<th colspan="3"/> | |||||
<td>table</td> | |||||
</tr> | |||||
<tr> | |||||
<th colspan="3"/> | |||||
<td>table-caption</td> | |||||
</tr> | |||||
<tr> | |||||
<th colspan="3"/> | |||||
<td>table-cell</td> | |||||
</tr> | |||||
<tr> | |||||
<td>is-viewport-area</td> | |||||
<td></td> | |||||
<td> | |||||
<link href= | |||||
"file:///home/pbw/doc/web/xsl/spec/slice4.html#area-common" | |||||
>4.2.2 Common Traits</link> | |||||
</td> | |||||
</tr> | |||||
<tr> | |||||
<td>top-position</td> | |||||
</tr> | |||||
<tr> | |||||
<td>bottom-position</td> | |||||
</tr> | |||||
<tr> | |||||
<td>left-position</td> | |||||
</tr> | |||||
<tr> | |||||
<td>right-position</td> | |||||
</tr> | |||||
<tr> | |||||
<td>left-offset</td> | |||||
</tr> | |||||
<tr> | |||||
<td>top-offset</td> | |||||
</tr> | |||||
<tr> | |||||
<td>is-first</td> | |||||
</tr> | |||||
<tr> | |||||
<td>is-last</td> | |||||
</tr> | |||||
<tr> | |||||
<td>generated-by</td> | |||||
</tr> | |||||
<tr> | |||||
<td>returned-by</td> | |||||
</tr> | |||||
<tr> | |||||
<td>nominal-font</td> | |||||
</tr> | |||||
<tr> | |||||
<td>blink</td> | |||||
<td></td> | |||||
<td> | |||||
<link href= | |||||
"file:///home/pbw/doc/web/xsl/spec/slice5.html#refine-text-decoration" | |||||
>5.5.6 Text-decoration Property | |||||
</link> | |||||
</td> | |||||
<td> | |||||
<link href= | |||||
"file:///home/pbw/doc/web/xsl/spec/slice7.html#text-decoration" | |||||
>7.16.4 "text-decoration" | |||||
</link> | |||||
</td> | |||||
</tr> | |||||
<tr> | |||||
<td>underline-score</td> | |||||
<td></td> | |||||
<td> | |||||
<link href= | |||||
"file:///home/pbw/doc/web/xsl/spec/slice5.html#refine-text-decoration" | |||||
>5.5.6 Text-decoration Property | |||||
</link> | |||||
</td> | |||||
<td> | |||||
<link href= | |||||
"file:///home/pbw/doc/web/xsl/spec/slice7.html#text-decoration" | |||||
>7.16.4 "text-decoration" | |||||
</link> | |||||
</td> | |||||
</tr> | |||||
<tr> | |||||
<td>underline-score-color</td> | |||||
<td></td> | |||||
<td> | |||||
<link href= | |||||
"file:///home/pbw/doc/web/xsl/spec/slice5.html#refine-text-decoration" | |||||
>5.5.6 Text-decoration Property | |||||
</link> | |||||
</td> | |||||
<td> | |||||
<link href= | |||||
"file:///home/pbw/doc/web/xsl/spec/slice7.html#text-decoration" | |||||
>7.16.4 "text-decoration" | |||||
</link> | |||||
</td> | |||||
</tr> | |||||
<tr> | |||||
<td>overline-score</td> | |||||
<td></td> | |||||
<td> | |||||
<link href= | |||||
"file:///home/pbw/doc/web/xsl/spec/slice5.html#refine-text-decoration" | |||||
>5.5.6 Text-decoration Property | |||||
</link> | |||||
</td> | |||||
<td> | |||||
<link href= | |||||
"file:///home/pbw/doc/web/xsl/spec/slice7.html#text-decoration" | |||||
>7.16.4 "text-decoration" | |||||
</link> | |||||
</td> | |||||
</tr> | |||||
<tr> | |||||
<td>overline-score-color</td> | |||||
<td></td> | |||||
<td> | |||||
<link href= | |||||
"file:///home/pbw/doc/web/xsl/spec/slice5.html#refine-text-decoration" | |||||
>5.5.6 Text-decoration Property | |||||
</link> | |||||
</td> | |||||
<td> | |||||
<link href= | |||||
"file:///home/pbw/doc/web/xsl/spec/slice7.html#text-decoration" | |||||
>7.16.4 "text-decoration" | |||||
</link> | |||||
</td> | |||||
</tr> | |||||
<tr> | |||||
<td>through-score</td> | |||||
<td></td> | |||||
<td> | |||||
<link href= | |||||
"file:///home/pbw/doc/web/xsl/spec/slice5.html#refine-text-decoration" | |||||
>5.5.6 Text-decoration Property | |||||
</link> | |||||
</td> | |||||
<td> | |||||
<link href= | |||||
"file:///home/pbw/doc/web/xsl/spec/slice7.html#text-decoration" | |||||
>7.16.4 "text-decoration" | |||||
</link> | |||||
</td> | |||||
</tr> | |||||
<tr> | |||||
<td>through-score-color</td> | |||||
<td></td> | |||||
<td> | |||||
<link href= | |||||
"file:///home/pbw/doc/web/xsl/spec/slice5.html#refine-text-decoration" | |||||
>5.5.6 Text-decoration Property | |||||
</link> | |||||
</td> | |||||
<td> | |||||
<link href= | |||||
"file:///home/pbw/doc/web/xsl/spec/slice7.html#text-decoration" | |||||
>7.16.4 "text-decoration" | |||||
</link> | |||||
</td> | |||||
</tr> | |||||
</table> | |||||
</s1> | |||||
</body> | |||||
</document> |