git-svn-id: https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk@195684 13f79535-47bb-0310-9956-ffa450edef68tags/Alt-Design-integration-base
@@ -9,7 +9,7 @@ Exp pbw $ --> | |||
<title>AbsolutePosition diagram</title> | |||
<authors> | |||
<person id="pbw" name="Peter B. West" | |||
email="pbwest@powerup.com.au"/> | |||
email="pbwest@powerup.com.au"/> | |||
</authors> | |||
</header> | |||
<body> |
@@ -8,7 +8,7 @@ | |||
<title>BorderCommonStyle diagram</title> | |||
<authors> | |||
<person id="pbw" name="Peter B. West" | |||
email="pbwest@powerup.com.au"/> | |||
email="pbwest@powerup.com.au"/> | |||
</authors> | |||
</header> | |||
<body> |
@@ -9,7 +9,7 @@ | |||
<title>..fo.PropNames diagram</title> | |||
<authors> | |||
<person id="pbw" name="Peter B. West" | |||
email="pbwest@powerup.com.au"/> | |||
email="pbwest@powerup.com.au"/> | |||
</authors> | |||
</header> | |||
<body> |
@@ -9,7 +9,7 @@ | |||
<title>..fo.Properties diagram</title> | |||
<authors> | |||
<person id="pbw" name="Peter B. West" | |||
email="pbwest@powerup.com.au"/> | |||
email="pbwest@powerup.com.au"/> | |||
</authors> | |||
</header> | |||
<body> |
@@ -8,7 +8,7 @@ | |||
<title>..fo.PropertyConsts diagram</title> | |||
<authors> | |||
<person id="pbw" name="Peter B. West" | |||
email="pbwest@powerup.com.au"/> | |||
email="pbwest@powerup.com.au"/> | |||
</authors> | |||
</header> | |||
<body> |
@@ -9,7 +9,7 @@ | |||
<title>VerticalAlign diagram</title> | |||
<authors> | |||
<person id="pbw" name="Peter B. West" | |||
email="pbwest@powerup.com.au"/> | |||
email="pbwest@powerup.com.au"/> | |||
</authors> | |||
</header> | |||
<body> |
@@ -14,153 +14,153 @@ | |||
<!-- one of (anchor s1) --> | |||
<s1 title="An alternative properties implementation"> | |||
<note> | |||
The following discussion focusses on the relationship between | |||
Flow Objects in the Flow Object tree, and properties. There | |||
is no (or only passing) discussion of the relationship between | |||
properties and traits, and by extension, between properties | |||
and the Area tree. The discussion is illustrated with some | |||
pseudo-UML diagrams. | |||
The following discussion focusses on the relationship between | |||
Flow Objects in the Flow Object tree, and properties. There | |||
is no (or only passing) discussion of the relationship between | |||
properties and traits, and by extension, between properties | |||
and the Area tree. The discussion is illustrated with some | |||
pseudo-UML diagrams. | |||
</note> | |||
<p> | |||
Property handling is complex and expensive. Varying numbers of | |||
properties apply to individual Flow Objects | |||
<strong>(FOs)</strong> in the <strong>FO | |||
tree </strong> but any property may effectively be | |||
assigned a value on any element of the tree. If that property | |||
is inheritable, its defined value will then be available to | |||
any children of the defining FO. | |||
Property handling is complex and expensive. Varying numbers of | |||
properties apply to individual Flow Objects | |||
<strong>(FOs)</strong> in the <strong>FO | |||
tree </strong> but any property may effectively be | |||
assigned a value on any element of the tree. If that property | |||
is inheritable, its defined value will then be available to | |||
any children of the defining FO. | |||
</p> | |||
<note> | |||
<em>(XSL 1.0 Rec)</em> <strong>5.1.4 Inheritance</strong> | |||
...The inheritable properties can be placed on any formatting | |||
object. | |||
<em>(XSL 1.0 Rec)</em> <strong>5.1.4 Inheritance</strong> | |||
...The inheritable properties can be placed on any formatting | |||
object. | |||
</note> | |||
<p> | |||
Even if the value is not inheritable, it may be accessed by | |||
its children through the <code>inherit</code> keyword or the | |||
<code>from-parent()</code> core function, and potentially by | |||
any of its descendents through the | |||
<code>from-nearest-specified-value()</code> core function. | |||
Even if the value is not inheritable, it may be accessed by | |||
its children through the <code>inherit</code> keyword or the | |||
<code>from-parent()</code> core function, and potentially by | |||
any of its descendents through the | |||
<code>from-nearest-specified-value()</code> core function. | |||
</p> | |||
<p> | |||
In addition to the assigned values of properties, almost every | |||
property has an <strong>initial value</strong> which is used | |||
when no value has been assigned. | |||
In addition to the assigned values of properties, almost every | |||
property has an <strong>initial value</strong> which is used | |||
when no value has been assigned. | |||
</p> | |||
<s2 title="The history problem"> | |||
<p> | |||
The difficulty and expense of handling properties comes from | |||
this univeral inheritance possibility. The list of properties | |||
which are assigned values on any particular <em>FO</em> | |||
element will not generally be large, but a current value is | |||
required for each property which applies to the <em>FO</em> | |||
being processed. | |||
The difficulty and expense of handling properties comes from | |||
this univeral inheritance possibility. The list of properties | |||
which are assigned values on any particular <em>FO</em> | |||
element will not generally be large, but a current value is | |||
required for each property which applies to the <em>FO</em> | |||
being processed. | |||
</p> | |||
<p> | |||
The environment from which these values may be selected | |||
includes, for each <em>FO</em>, for each applicable property, | |||
the value assigned on this <em>FO</em>, the value which | |||
applied to the parent of this <em>FO</em>, the nearest value | |||
specified on an ancestor of this element, and the initial | |||
value of the property. | |||
The environment from which these values may be selected | |||
includes, for each <em>FO</em>, for each applicable property, | |||
the value assigned on this <em>FO</em>, the value which | |||
applied to the parent of this <em>FO</em>, the nearest value | |||
specified on an ancestor of this element, and the initial | |||
value of the property. | |||
</p> | |||
</s2> | |||
<s2 title="Data requirement and structure"> | |||
<p> | |||
This determines the minimum set of properties and associated | |||
property value assignments that is necessary for the | |||
processing of any individual <em>FO</em>. Implicit in this | |||
set is the set of properties and associated values, | |||
effective on the current <em>FO</em>, that were assigned on | |||
that <em>FO</em>. | |||
</p> | |||
<p> | |||
This minimum requirement - the initial value, the | |||
nearest ancestor specified value, the parent computed value | |||
and the value assigned to the current element - | |||
suggests a stack implementation. | |||
</p> | |||
<p> | |||
This determines the minimum set of properties and associated | |||
property value assignments that is necessary for the | |||
processing of any individual <em>FO</em>. Implicit in this | |||
set is the set of properties and associated values, | |||
effective on the current <em>FO</em>, that were assigned on | |||
that <em>FO</em>. | |||
</p> | |||
<p> | |||
This minimum requirement - the initial value, the | |||
nearest ancestor specified value, the parent computed value | |||
and the value assigned to the current element - | |||
suggests a stack implementation. | |||
</p> | |||
</s2> | |||
<s2 title="Stack considerations"> | |||
<p> | |||
One possibility is to push to the stack only a minimal set | |||
of required elements. When a value is assigned, the | |||
relevant form or forms of that value (specified, computed, | |||
actual) are pushed onto the stack. As long as each | |||
<em>FO</em> maintains a list of the properties which were | |||
assigned from it, the value can be popped when the focus of | |||
FO processing retreats back up the <em>FO</em> tree. | |||
</p> | |||
<p> | |||
The complication is that, for elements which are not | |||
automatically inherited, when an <em>FO</em> is encountered | |||
which does <strong>not</strong> assign a value to the | |||
property, the initial value must either be already at the | |||
top of the stack or be pushed onto the stack. | |||
</p> | |||
<p> | |||
As a first approach, the simplest procedure may be to push a | |||
current value onto the stack for every element - initial | |||
values for non-inherited properties and the parental value | |||
otherwise. Then perform any processing of assigned values. | |||
This simplifies program logic at what is hopefully a small | |||
cost in memory and processing time. It may be tuned in a | |||
later iteration. | |||
</p> | |||
<s3 title="Stack implementation"> | |||
<p> | |||
Initial attempts at this implementation have used | |||
<code>LinkedList</code>s as the stacks, on the assumption | |||
that | |||
</p> | |||
<sl> | |||
<!-- one of (dl sl ul ol li) --> | |||
<li>random access would not be required</li> | |||
<li> | |||
pushing and popping of list elements requires nearly | |||
constant (low) time | |||
</li> | |||
<li> no penalty for first addition to an empty list</li> | |||
<li>efficient access to both bottom and top of stack</li> | |||
</sl> | |||
<p> | |||
However, it may be required to perform stack access | |||
operations from an arbitrary place on the stack, in which | |||
case it would probably be more efficient to use | |||
<code>ArrayList</code>s instead. | |||
</p> | |||
</s3> | |||
<p> | |||
One possibility is to push to the stack only a minimal set | |||
of required elements. When a value is assigned, the | |||
relevant form or forms of that value (specified, computed, | |||
actual) are pushed onto the stack. As long as each | |||
<em>FO</em> maintains a list of the properties which were | |||
assigned from it, the value can be popped when the focus of | |||
FO processing retreats back up the <em>FO</em> tree. | |||
</p> | |||
<p> | |||
The complication is that, for elements which are not | |||
automatically inherited, when an <em>FO</em> is encountered | |||
which does <strong>not</strong> assign a value to the | |||
property, the initial value must either be already at the | |||
top of the stack or be pushed onto the stack. | |||
</p> | |||
<p> | |||
As a first approach, the simplest procedure may be to push a | |||
current value onto the stack for every element - initial | |||
values for non-inherited properties and the parental value | |||
otherwise. Then perform any processing of assigned values. | |||
This simplifies program logic at what is hopefully a small | |||
cost in memory and processing time. It may be tuned in a | |||
later iteration. | |||
</p> | |||
<s3 title="Stack implementation"> | |||
<p> | |||
Initial attempts at this implementation have used | |||
<code>LinkedList</code>s as the stacks, on the assumption | |||
that | |||
</p> | |||
<sl> | |||
<!-- one of (dl sl ul ol li) --> | |||
<li>random access would not be required</li> | |||
<li> | |||
pushing and popping of list elements requires nearly | |||
constant (low) time | |||
</li> | |||
<li> no penalty for first addition to an empty list</li> | |||
<li>efficient access to both bottom and top of stack</li> | |||
</sl> | |||
<p> | |||
However, it may be required to perform stack access | |||
operations from an arbitrary place on the stack, in which | |||
case it would probably be more efficient to use | |||
<code>ArrayList</code>s instead. | |||
</p> | |||
</s3> | |||
</s2> | |||
<s2 title="Class vs instance"> | |||
<p> | |||
An individual stack would contain values for a particular | |||
property, and the context of the stack is the property class | |||
as a whole. The property instances would be represented by | |||
the individual values on the stack. If properties are to be | |||
represented as instantiations of the class, the stack | |||
entries would presumably be references to, or at least | |||
referenced from, individual property objects. However, the | |||
most important information about individual property | |||
instances is the value assigned, and the relationship of | |||
this property object to its ancestors and its descendents. | |||
Other information would include the ownership of a property | |||
instance by a particular <em>FO</em>, and, in the other | |||
direction, the membership of the property in the set of | |||
properties for which an <em>FO</em> has defined values. | |||
</p> | |||
<p> | |||
In the presence of a stack, however, none of this required | |||
information mandates the instantiation of properties. All | |||
of the information mentioned so far can be effectively | |||
represented by a stack position and a link to an | |||
<em>FO</em>. If the property stack is maintained in | |||
parallel with a stack of <em>FOs</em>, even that link is | |||
implicit in the stack position. | |||
</p> | |||
<p> | |||
An individual stack would contain values for a particular | |||
property, and the context of the stack is the property class | |||
as a whole. The property instances would be represented by | |||
the individual values on the stack. If properties are to be | |||
represented as instantiations of the class, the stack | |||
entries would presumably be references to, or at least | |||
referenced from, individual property objects. However, the | |||
most important information about individual property | |||
instances is the value assigned, and the relationship of | |||
this property object to its ancestors and its descendents. | |||
Other information would include the ownership of a property | |||
instance by a particular <em>FO</em>, and, in the other | |||
direction, the membership of the property in the set of | |||
properties for which an <em>FO</em> has defined values. | |||
</p> | |||
<p> | |||
In the presence of a stack, however, none of this required | |||
information mandates the instantiation of properties. All | |||
of the information mentioned so far can be effectively | |||
represented by a stack position and a link to an | |||
<em>FO</em>. If the property stack is maintained in | |||
parallel with a stack of <em>FOs</em>, even that link is | |||
implicit in the stack position. | |||
</p> | |||
</s2> | |||
<p> | |||
<strong>Next:</strong> <link href= "classes-overview.html" | |||
>property classes overview.</link> | |||
<strong>Next:</strong> <link href= "classes-overview.html" | |||
>property classes overview.</link> | |||
</p> | |||
</s1> | |||
</body> |
@@ -9,192 +9,192 @@ | |||
<title>Property classes overview</title> | |||
<authors> | |||
<person id="pbw" name="Peter B. West" | |||
email="pbwest@powerup.com.au"/> | |||
email="pbwest@powerup.com.au"/> | |||
</authors> | |||
</header> | |||
<body> | |||
<!-- one of (anchor s1) --> | |||
<s1 title="Classes overview"> | |||
<s2 title="The class of all properties"> | |||
<p> | |||
If individual properties can have a "virtual reality" on the | |||
stack, where is the stack itself to be instantiated? One | |||
possibility is to have the stacks as <code>static</code> | |||
data structures within the individual property classes. | |||
However, the reduction of individual property instances to | |||
stack entries allows the possibility of further | |||
virtualization of property classes. If the individual | |||
properties can be represented by an integer, i.e. a | |||
<code>static final int</code>, the set of individual | |||
property stacks can be collected together into one array. | |||
Where to put such an overall collection? Creating an | |||
über-class to accommodate everything that applies to | |||
property classes as a whole allows this array to be defined | |||
as a <em><code>static final</code> something[]</em>. | |||
</p> | |||
<p> | |||
If individual properties can have a "virtual reality" on the | |||
stack, where is the stack itself to be instantiated? One | |||
possibility is to have the stacks as <code>static</code> | |||
data structures within the individual property classes. | |||
However, the reduction of individual property instances to | |||
stack entries allows the possibility of further | |||
virtualization of property classes. If the individual | |||
properties can be represented by an integer, i.e. a | |||
<code>static final int</code>, the set of individual | |||
property stacks can be collected together into one array. | |||
Where to put such an overall collection? Creating an | |||
über-class to accommodate everything that applies to | |||
property classes as a whole allows this array to be defined | |||
as a <em><code>static final</code> something[]</em>. | |||
</p> | |||
</s2> | |||
<s2 title="The overall property classes"> | |||
<p> | |||
This approach has been taken for the experimental code. | |||
Rather than simply creating a overall class containing | |||
common elements of properties and acting as a superclass, | |||
advantage has been taken of the facility for nesting of | |||
top-level classes. All of the individual property classes | |||
are nested within the <code>Properties</code> class. | |||
This has advantages and disadvantages. | |||
</p> | |||
<dl> | |||
<dt>Disadvantages</dt> | |||
<dd> | |||
The file becomes extremely cumbersome. This can cause | |||
problems with "intelligent" editors. E.g. | |||
<em>XEmacs</em> syntax highlighting virtually grinds to a | |||
halt with the current version of this file.<br/> <br/> | |||
Possible problems with IDEs. There may be speed problems | |||
or even overflow problems with various IDEs. The current | |||
version of this and related files had only been tried with | |||
the <em>[X]Emacs JDE</em> environment, without difficulties | |||
apart from the editor speed problems mentioned | |||
above.<br/> <br/> | |||
Retro look and feel. Not the done Java thing.<br/> <br/> | |||
</dd> | |||
<dt>Advantages</dt> | |||
<dd> | |||
Everything to do with properties in the one place (more or | |||
less.)<br/> <br/> | |||
Eliminates the need for a large part of the (sometimes) | |||
necessary evil of code generation. The One Big File of | |||
<code>foproperties.xml</code>, with its ancillary xsl, is | |||
absorbed into the One Bigger File of | |||
<code>Properties.java</code>. The huge advantage of this | |||
is that it <strong>is</strong> Java. | |||
</dd> | |||
</dl> | |||
<p> | |||
This approach has been taken for the experimental code. | |||
Rather than simply creating a overall class containing | |||
common elements of properties and acting as a superclass, | |||
advantage has been taken of the facility for nesting of | |||
top-level classes. All of the individual property classes | |||
are nested within the <code>Properties</code> class. | |||
This has advantages and disadvantages. | |||
</p> | |||
<dl> | |||
<dt>Disadvantages</dt> | |||
<dd> | |||
The file becomes extremely cumbersome. This can cause | |||
problems with "intelligent" editors. E.g. | |||
<em>XEmacs</em> syntax highlighting virtually grinds to a | |||
halt with the current version of this file.<br/> <br/> | |||
Possible problems with IDEs. There may be speed problems | |||
or even overflow problems with various IDEs. The current | |||
version of this and related files had only been tried with | |||
the <em>[X]Emacs JDE</em> environment, without difficulties | |||
apart from the editor speed problems mentioned | |||
above.<br/> <br/> | |||
Retro look and feel. Not the done Java thing.<br/> <br/> | |||
</dd> | |||
<dt>Advantages</dt> | |||
<dd> | |||
Everything to do with properties in the one place (more or | |||
less.)<br/> <br/> | |||
Eliminates the need for a large part of the (sometimes) | |||
necessary evil of code generation. The One Big File of | |||
<code>foproperties.xml</code>, with its ancillary xsl, is | |||
absorbed into the One Bigger File of | |||
<code>Properties.java</code>. The huge advantage of this | |||
is that it <strong>is</strong> Java. | |||
</dd> | |||
</dl> | |||
</s2> | |||
<s2 title="The property information classes"> | |||
<p> | |||
In fact, in order to keep the size of the file down to more | |||
a more manageable level, the property information classes of | |||
static data and methods have been split tentatively into | |||
three: | |||
</p> | |||
<figure src="PropertyStaticsOverview.png" alt="Top level | |||
property classes"/> | |||
<dl> | |||
<dt><link href="PropNames.html">PropNames</link></dt> | |||
<dd> | |||
Contains an array, <code>propertyNames</code>, of the names of | |||
all properties, and a set of enumeration constants, one | |||
for each property name in the <code>PropertyNames</code> | |||
array. These constants index the name of the properties | |||
in <code>propertyNames</code>, and must be manually kept in | |||
sync with the entries in the array. (This was the last of | |||
the classes split off from the original single class; | |||
hence the naming tiredness.) | |||
<br/> <br/> | |||
</dd> | |||
<dt><link href="PropertyConsts.html">PropertyConsts</link></dt> | |||
<dd> | |||
Contains two basic sets of data:<br/> | |||
Property-indexed arrays and property set | |||
definitions.<br/> <br/> | |||
<strong>Property-indexed arrays</strong> are elaborations | |||
of the property indexing idea discussed in relation to the | |||
arrays of property stacks. One of the arrays is<br/> <br/> | |||
<code>public static final LinkedList[] | |||
propertyStacks</code><br/> <br/> | |||
This is an array of stacks, implemented as | |||
<code>LinkedList</code>s, one for each property.<br/> <br/> | |||
The other arrays provide indexed access to fields which | |||
are, in most cases, common to all of the properties. An | |||
exception is<br/> <br/> | |||
<code>public static final Method[] | |||
complexMethods</code><br/> <br/> | |||
which contains a reference to the method | |||
<code>complex()</code> which is only defined for | |||
properties which have complex value parsing requirements. | |||
It is likely that a similar array will be defined for | |||
properties which allow a value of <em>auto</em>.<br/> <br/> | |||
The property-indexed arrays are initialized by | |||
<code>static</code> initializers in this class. The | |||
<code>PropNames</code> class and | |||
<code>Properties</code> | |||
nested classes are scanned in order to obtain or derive | |||
the data necessary for initialization.<br/> <br/> | |||
<strong>Property set definitions</strong> are | |||
<code>HashSet</code>s of properties (represented by | |||
integer constants) which belong to each of the categories | |||
of properties defined. They are used to simplify the | |||
assignment of property sets to individual FOs. | |||
Representative <code>HashSet</code>s include | |||
<em>backgroundProps</em> and | |||
<em>tableProps</em>.<br/> <br/> | |||
</dd> | |||
<dt><link href="Properties.html">Properties</link></dt> | |||
<dd> | |||
<br/> | |||
This class contains only sets of constants for use by the | |||
individual property classes, but it also importantly | |||
serves as a container for all of the property classes, and | |||
some convenience pseudo-property classes.<br/> <br/> | |||
<strong>Constants sets</strong> include:<br/> <br/> | |||
<em>Datatype constants</em>. A bitmap set of | |||
integer constants over a possible range of 2^0 to 2^31 | |||
(represented as -2147483648). E.g.<br/> | |||
INTEGER = 1<br/> | |||
ENUM = 524288<br/> <br/> | |||
Some of the definitions are bit-ORed | |||
combinations of the basic values. Used to set the | |||
<em>dataTypes</em> field of the property | |||
classes.<br/> <br/> | |||
<em>Trait mapping constants</em>. A bitmap set of | |||
integer constants over a possible range of 2^0 to 2^31 | |||
(represented as -2147483648), representing the manner in | |||
which a property maps into a <em>trait</em>. Used to set | |||
the <code>traitMapping</code> field of the property | |||
classes.<br/> <br/> | |||
<em>Initial value constants</em>. A sequence of | |||
integer constants representing the datatype of the initial | |||
value of a property. Used to set the | |||
<code>initialValueType</code> field of the property | |||
classes.<br/> <br/> | |||
<em>Inheritance value constants</em>. A sequence | |||
of integer constants representing the way in which the | |||
property is normally inherited. Used to set the | |||
<code>inherited</code> field of the property | |||
classes.<br/> <br/> | |||
<strong>Nested property classes</strong>. The | |||
<em>Properties</em> class serves as the holding pen for | |||
all of the individual property classes, and for property | |||
pseudo-classes which contain data common to a number of | |||
actual properties, e.g. <em>ColorCommon</em>. | |||
</dd> | |||
</dl> | |||
<p> | |||
In fact, in order to keep the size of the file down to more | |||
a more manageable level, the property information classes of | |||
static data and methods have been split tentatively into | |||
three: | |||
</p> | |||
<figure src="PropertyStaticsOverview.png" alt="Top level | |||
property classes"/> | |||
<dl> | |||
<dt><link href="PropNames.html">PropNames</link></dt> | |||
<dd> | |||
Contains an array, <code>propertyNames</code>, of the names of | |||
all properties, and a set of enumeration constants, one | |||
for each property name in the <code>PropertyNames</code> | |||
array. These constants index the name of the properties | |||
in <code>propertyNames</code>, and must be manually kept in | |||
sync with the entries in the array. (This was the last of | |||
the classes split off from the original single class; | |||
hence the naming tiredness.) | |||
<br/> <br/> | |||
</dd> | |||
<dt><link href="PropertyConsts.html">PropertyConsts</link></dt> | |||
<dd> | |||
Contains two basic sets of data:<br/> | |||
Property-indexed arrays and property set | |||
definitions.<br/> <br/> | |||
<strong>Property-indexed arrays</strong> are elaborations | |||
of the property indexing idea discussed in relation to the | |||
arrays of property stacks. One of the arrays is<br/> <br/> | |||
<code>public static final LinkedList[] | |||
propertyStacks</code><br/> <br/> | |||
This is an array of stacks, implemented as | |||
<code>LinkedList</code>s, one for each property.<br/> <br/> | |||
The other arrays provide indexed access to fields which | |||
are, in most cases, common to all of the properties. An | |||
exception is<br/> <br/> | |||
<code>public static final Method[] | |||
complexMethods</code><br/> <br/> | |||
which contains a reference to the method | |||
<code>complex()</code> which is only defined for | |||
properties which have complex value parsing requirements. | |||
It is likely that a similar array will be defined for | |||
properties which allow a value of <em>auto</em>.<br/> <br/> | |||
The property-indexed arrays are initialized by | |||
<code>static</code> initializers in this class. The | |||
<code>PropNames</code> class and | |||
<code>Properties</code> | |||
nested classes are scanned in order to obtain or derive | |||
the data necessary for initialization.<br/> <br/> | |||
<strong>Property set definitions</strong> are | |||
<code>HashSet</code>s of properties (represented by | |||
integer constants) which belong to each of the categories | |||
of properties defined. They are used to simplify the | |||
assignment of property sets to individual FOs. | |||
Representative <code>HashSet</code>s include | |||
<em>backgroundProps</em> and | |||
<em>tableProps</em>.<br/> <br/> | |||
</dd> | |||
<dt><link href="Properties.html">Properties</link></dt> | |||
<dd> | |||
<br/> | |||
This class contains only sets of constants for use by the | |||
individual property classes, but it also importantly | |||
serves as a container for all of the property classes, and | |||
some convenience pseudo-property classes.<br/> <br/> | |||
<strong>Constants sets</strong> include:<br/> <br/> | |||
<em>Datatype constants</em>. A bitmap set of | |||
integer constants over a possible range of 2^0 to 2^31 | |||
(represented as -2147483648). E.g.<br/> | |||
INTEGER = 1<br/> | |||
ENUM = 524288<br/> <br/> | |||
Some of the definitions are bit-ORed | |||
combinations of the basic values. Used to set the | |||
<em>dataTypes</em> field of the property | |||
classes.<br/> <br/> | |||
<em>Trait mapping constants</em>. A bitmap set of | |||
integer constants over a possible range of 2^0 to 2^31 | |||
(represented as -2147483648), representing the manner in | |||
which a property maps into a <em>trait</em>. Used to set | |||
the <code>traitMapping</code> field of the property | |||
classes.<br/> <br/> | |||
<em>Initial value constants</em>. A sequence of | |||
integer constants representing the datatype of the initial | |||
value of a property. Used to set the | |||
<code>initialValueType</code> field of the property | |||
classes.<br/> <br/> | |||
<em>Inheritance value constants</em>. A sequence | |||
of integer constants representing the way in which the | |||
property is normally inherited. Used to set the | |||
<code>inherited</code> field of the property | |||
classes.<br/> <br/> | |||
<strong>Nested property classes</strong>. The | |||
<em>Properties</em> class serves as the holding pen for | |||
all of the individual property classes, and for property | |||
pseudo-classes which contain data common to a number of | |||
actual properties, e.g. <em>ColorCommon</em>. | |||
</dd> | |||
</dl> | |||
</s2> | |||
<p> | |||
<strong>Previous:</strong> <link href= | |||
"alt.properties.html" >alt.properties</link> | |||
<strong>Previous:</strong> <link href= | |||
"alt.properties.html" >alt.properties</link> | |||
</p> | |||
<p> | |||
<strong>Next:</strong> <link href= | |||
"properties-classes.html" >Properties classes</link> | |||
<strong>Next:</strong> <link href= | |||
"properties-classes.html" >Properties classes</link> | |||
</p> | |||
</s1> | |||
</body> |
@@ -14,204 +14,204 @@ | |||
<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> | |||
<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> |
@@ -15,103 +15,103 @@ | |||
<!-- 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. | |||
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. | |||
[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. | |||
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> | |||
<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> |
@@ -15,122 +15,122 @@ | |||
<!-- 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. | |||
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> | |||
<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"/> | |||
<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"/> | |||
<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> | |||
<note>To be developed.</note> | |||
</s2> | |||
</s1> | |||
</body> |
@@ -15,195 +15,195 @@ | |||
<!-- 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> | |||
<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> | |||
<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> | |||
<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> | |||
<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> | |||
<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> |
@@ -13,71 +13,71 @@ | |||
<person name="Peter B. West" email="pbwest@powerup.com.au"/> | |||
</authors> | |||
</header> | |||
<body> | |||
<s1 title="Alternative Design"> | |||
<p> | |||
This section of the FOP web site contains notes on approaches | |||
to an alternative design for FOP. The individual documents | |||
here are fragmentary, being notes of particular issues, | |||
without an overall framework as yet. | |||
This section of the FOP web site contains notes on approaches | |||
to an alternative design for FOP. The individual documents | |||
here are fragmentary, being notes of particular issues, | |||
without an overall framework as yet. | |||
</p> | |||
<p> | |||
The main aims of this redesign effort are: | |||
The main aims of this redesign effort are: | |||
</p> | |||
<ul> | |||
<li>full conformance with the Recommendation</li> | |||
<li>increased performance</li> | |||
<li>reduced memory footprint</li> | |||
<li>no limitation on the size of files</li> | |||
<li>full conformance with the Recommendation</li> | |||
<li>increased performance</li> | |||
<li>reduced memory footprint</li> | |||
<li>no limitation on the size of files</li> | |||
</ul> | |||
<p> | |||
In order to achieve these aims, the primary areas | |||
of design interest are: | |||
In order to achieve these aims, the primary areas | |||
of design interest are: | |||
</p> | |||
<ul> | |||
<li> | |||
Representing properties, for most purposes, as integers. | |||
</li> | |||
<li> | |||
Distributing FOP processing over a number of threads with | |||
single-point downstream communication and flow control by | |||
means of traditional producer/consumer queues. The threads | |||
so far under consideration are: | |||
<ul> | |||
<li>XML parser</li> | |||
<li>FO tree builder</li> | |||
<li>layout engine</li> | |||
<li>Area tree builder</li> | |||
</ul> | |||
</li> | |||
<li> | |||
Representing trees with explicit Tree objects, rather than | |||
as implicit relationships among other objects. | |||
</li> | |||
<li> | |||
Caching integrated into the tree node access methods. | |||
</li> | |||
<li> | |||
Representing properties, for most purposes, as integers. | |||
</li> | |||
<li> | |||
Distributing FOP processing over a number of threads with | |||
single-point downstream communication and flow control by | |||
means of traditional producer/consumer queues. The threads | |||
so far under consideration are: | |||
<ul> | |||
<li>XML parser</li> | |||
<li>FO tree builder</li> | |||
<li>layout engine</li> | |||
<li>Area tree builder</li> | |||
</ul> | |||
</li> | |||
<li> | |||
Representing trees with explicit Tree objects, rather than | |||
as implicit relationships among other objects. | |||
</li> | |||
<li> | |||
Caching integrated into the tree node access methods. | |||
</li> | |||
</ul> | |||
<s2 title="Status and availability"> | |||
<p> | |||
The <em>ALT DESIGN</em> effort is not taking place on the | |||
main line of development, represented by the <em>HEAD</em> | |||
tag on the CVS trunk. The source is available via the | |||
FOP_0-20-0_Alt-Design tag. This code has only a crude, | |||
non-<em>Ant</em> build environment, and is expected only to | |||
compile at this stage. Only the parser stage and the first | |||
stage of FO tree building is present. However, the first | |||
example of producer/consumer binding is working, the Tree | |||
class with inner Tree.Node and inner | |||
Tree.Node.<em>iterators</em> classes are available and | |||
working. Property handling is quite advanced, and is likely | |||
to be almost complete some time in July, 2002. | |||
</p> | |||
<p> | |||
Only <link href="mailto:pbwest@powerup.com.au">Peter | |||
West</link> is working on the ALT DESIGN sub-project. | |||
</p> | |||
<p> | |||
The <em>ALT DESIGN</em> effort is not taking place on the | |||
main line of development, represented by the <em>HEAD</em> | |||
tag on the CVS trunk. The source is available via the | |||
FOP_0-20-0_Alt-Design tag. This code has only a crude, | |||
non-<em>Ant</em> build environment, and is expected only to | |||
compile at this stage. Only the parser stage and the first | |||
stage of FO tree building is present. However, the first | |||
example of producer/consumer binding is working, the Tree | |||
class with inner Tree.Node and inner | |||
Tree.Node.<em>iterators</em> classes are available and | |||
working. Property handling is quite advanced, and is likely | |||
to be almost complete some time in July, 2002. | |||
</p> | |||
<p> | |||
Only <link href="mailto:pbwest@powerup.com.au">Peter | |||
West</link> is working on the ALT DESIGN sub-project. | |||
</p> | |||
</s2> | |||
</s1> | |||
@@ -15,94 +15,94 @@ | |||
<!-- one of (anchor s1) --> | |||
<s1 title="Keeps and breaks in layout galleys"> | |||
<p> | |||
The <link href= "galleys.html" >layout galleys</link> and the | |||
<link href= "galleys.html#layout-tree" >layout tree</link> | |||
which is their context have been discussed elsewhere. Here we | |||
discuss a possible method of implementing keeps and breaks | |||
within the context of layout galleys and the layout tree. | |||
The <link href= "galleys.html" >layout galleys</link> and the | |||
<link href= "galleys.html#layout-tree" >layout tree</link> | |||
which is their context have been discussed elsewhere. Here we | |||
discuss a possible method of implementing keeps and breaks | |||
within the context of layout galleys and the layout tree. | |||
</p> | |||
<s2 title="Breaks"> | |||
<p> | |||
Breaks may be handled by inserting a column- or page-break | |||
pseudo-object into the galley stream. For break-before, the | |||
object would be inserted before the area in which the flow | |||
object, to which the property is attached, is leading. If | |||
the flow object is leading in no ancestor context, the | |||
pseudo-object is inserted before the object itself. | |||
Corresponding considerations apply for break-after. | |||
Selection of the position for these objects will be further | |||
examined in the discussion on keeps. | |||
</p> | |||
<p> | |||
Breaks may be handled by inserting a column- or page-break | |||
pseudo-object into the galley stream. For break-before, the | |||
object would be inserted before the area in which the flow | |||
object, to which the property is attached, is leading. If | |||
the flow object is leading in no ancestor context, the | |||
pseudo-object is inserted before the object itself. | |||
Corresponding considerations apply for break-after. | |||
Selection of the position for these objects will be further | |||
examined in the discussion on keeps. | |||
</p> | |||
</s2> | |||
<s2 title="Keeps"> | |||
<p> | |||
Conceptually, all keeps can be represented by a | |||
keep-together pseudo-area. The keep-together property | |||
itself is expressed during layout by wrapping all of the | |||
generated areas in a keep-together area. Keep-with-previous | |||
on formatting object A becomes a keep-together area spanning | |||
the first non-blank normal area leaf node, L, generated by A | |||
or its offspring, and the last non-blank normal area leaf | |||
node preceding L in the area tree. Likewise, keep-with-next | |||
on formatting object A becomes a keep-together area spanning | |||
the last non-blank normal area leaf node, L, generated by A | |||
or its offspring, and the first non-blank normal area leaf | |||
node following L in the area tree. | |||
<br/>TODO REWORK THIS for block vs inline | |||
</p> | |||
<p> | |||
The obvious problem with this arrangement is that the | |||
keep-together area violate the hierarachical arrangement of | |||
the layout tree. They form a concurrent structure focussed | |||
on the leaf nodes. This seems to be the essential problem | |||
of handling keep-with-(previous/next); that it cuts across | |||
the otherwise tree-structured flow of processing. Such | |||
problems are endemic in page layout. | |||
</p> | |||
<p> | |||
In any case, it seems that the relationships between areas | |||
that are of interest in keep processing need some form of | |||
direct expression, parallel to the layout tree itself. | |||
Restricting ourselves too block-level elements, and looking | |||
only at the simple block stacking cases, we get a diagram | |||
like the attached PNG. In order to track the relationships | |||
through the tree, we need four sets of links. | |||
</p> | |||
<p> | |||
<strong>Figure 1</strong> | |||
</p> | |||
<anchor id="Figure1"/> | |||
<figure src="block-stacking.png" alt="Simple block-stacking | |||
diagram"/> | |||
<p> | |||
The three basic links are: | |||
</p> | |||
<ul> | |||
<!-- one of (dl sl ul ol li) --> | |||
<li>Leading edge to leading edge of first normal child.</li> | |||
<li>Trailing edge to leading edge of next normal | |||
sibling.</li> | |||
<li>Trailing edge to trailing edge of parent.</li> | |||
</ul> | |||
<p> | |||
Superimposed on the basic links are bridging links which | |||
span adjacent sets of links. These spanning links are the | |||
tree violators, and give direct access to the areas which | |||
are of interest in keep processing. They could be | |||
implemented as double-linked lists, either within the layout | |||
tree nodes or as separate structures. Gaps in the spanning | |||
links are joined by simply reproducing the single links, as | |||
in the diagram. The whole layout tree for a page is | |||
effectively threaded in order of interest, as far as keeps | |||
are concerned. | |||
</p> | |||
<p> | |||
The bonus of this structure is that it looks like a superset | |||
of the stacking constraints. It gives direct access to all | |||
sets of adjacent edges and sets of edges whose space | |||
specifiers need to be resolved. Fences can be easily enough | |||
detected during the process of space resolution. | |||
</p> | |||
<p> | |||
Conceptually, all keeps can be represented by a | |||
keep-together pseudo-area. The keep-together property | |||
itself is expressed during layout by wrapping all of the | |||
generated areas in a keep-together area. Keep-with-previous | |||
on formatting object A becomes a keep-together area spanning | |||
the first non-blank normal area leaf node, L, generated by A | |||
or its offspring, and the last non-blank normal area leaf | |||
node preceding L in the area tree. Likewise, keep-with-next | |||
on formatting object A becomes a keep-together area spanning | |||
the last non-blank normal area leaf node, L, generated by A | |||
or its offspring, and the first non-blank normal area leaf | |||
node following L in the area tree. | |||
<br/>TODO REWORK THIS for block vs inline | |||
</p> | |||
<p> | |||
The obvious problem with this arrangement is that the | |||
keep-together area violate the hierarachical arrangement of | |||
the layout tree. They form a concurrent structure focussed | |||
on the leaf nodes. This seems to be the essential problem | |||
of handling keep-with-(previous/next); that it cuts across | |||
the otherwise tree-structured flow of processing. Such | |||
problems are endemic in page layout. | |||
</p> | |||
<p> | |||
In any case, it seems that the relationships between areas | |||
that are of interest in keep processing need some form of | |||
direct expression, parallel to the layout tree itself. | |||
Restricting ourselves too block-level elements, and looking | |||
only at the simple block stacking cases, we get a diagram | |||
like the attached PNG. In order to track the relationships | |||
through the tree, we need four sets of links. | |||
</p> | |||
<p> | |||
<strong>Figure 1</strong> | |||
</p> | |||
<anchor id="Figure1"/> | |||
<figure src="block-stacking.png" alt="Simple block-stacking | |||
diagram"/> | |||
<p> | |||
The three basic links are: | |||
</p> | |||
<ul> | |||
<!-- one of (dl sl ul ol li) --> | |||
<li>Leading edge to leading edge of first normal child.</li> | |||
<li>Trailing edge to leading edge of next normal | |||
sibling.</li> | |||
<li>Trailing edge to trailing edge of parent.</li> | |||
</ul> | |||
<p> | |||
Superimposed on the basic links are bridging links which | |||
span adjacent sets of links. These spanning links are the | |||
tree violators, and give direct access to the areas which | |||
are of interest in keep processing. They could be | |||
implemented as double-linked lists, either within the layout | |||
tree nodes or as separate structures. Gaps in the spanning | |||
links are joined by simply reproducing the single links, as | |||
in the diagram. The whole layout tree for a page is | |||
effectively threaded in order of interest, as far as keeps | |||
are concerned. | |||
</p> | |||
<p> | |||
The bonus of this structure is that it looks like a superset | |||
of the stacking constraints. It gives direct access to all | |||
sets of adjacent edges and sets of edges whose space | |||
specifiers need to be resolved. Fences can be easily enough | |||
detected during the process of space resolution. | |||
</p> | |||
</s2> | |||
</s1> | |||
</body> |
@@ -15,125 +15,125 @@ | |||
<!-- one of (anchor s1) --> | |||
<s1 title="fo.Properties and the nested properties classes"> | |||
<figure src="PropertyClasses.png" alt="Nested property and | |||
top-level classes"/> | |||
top-level classes"/> | |||
<s2 title="Nested property classes"> | |||
<p> | |||
Given the intention that individual properties have only a | |||
<em>virtual</em> instantiation in the arrays of | |||
<code>PropertyConsts</code>, these classes are intended to | |||
remain as repositories of static data and methods. The name | |||
of each property is entered in the | |||
<code>PropNames.propertyNames</code> array of | |||
<code>String</code>s, and each has a unique integer constant | |||
defined, corresponding to the offset of the property name in | |||
that array. | |||
</p> | |||
<s3 title="Fields common to all classes"> | |||
<dl> | |||
<dt><code>final int dataTypes</code></dt> | |||
<dd> | |||
This field defines the allowable data types which may be | |||
assigned to the property. The value is chosen from the | |||
data type constants defined in <code>Properties</code>, and | |||
may consist of more than one of those constants, | |||
bit-ORed together. | |||
</dd> | |||
<dt><code>final int traitMapping</code></dt> | |||
<dd> | |||
This field defines the mapping of properties to traits | |||
in the <code>Area tree</code>. The value is chosen from the | |||
trait mapping constants defined in <code>Properties</code>, | |||
and may consist of more than one of those constants, | |||
bit-ORed together. | |||
</dd> | |||
<dt><code>final int initialValueType</code></dt> | |||
<dd> | |||
This field defines the data type of the initial value | |||
assigned to the property. The value is chosen from the | |||
initial value type constants defined in | |||
<code>Properties</code>. | |||
</dd> | |||
<dt><code>final int inherited</code></dt> | |||
<dd> | |||
This field defines the kind of inheritance applicable to | |||
the property. The value is chosen from the inheritance | |||
constants defined in <code>Properties</code>. | |||
</dd> | |||
</dl> | |||
</s3> | |||
<s3 title="Datatype dependent fields"> | |||
<dl> | |||
<dt>Enumeration types</dt> | |||
<dd> | |||
<strong><code>final String[] enums</code></strong><br/> | |||
This array contains the <code>NCName</code> text | |||
values of the enumeration. In the current | |||
implementation, it always contains a null value at | |||
<code>enum[0]</code>.<br/> <br/> | |||
<p> | |||
Given the intention that individual properties have only a | |||
<em>virtual</em> instantiation in the arrays of | |||
<code>PropertyConsts</code>, these classes are intended to | |||
remain as repositories of static data and methods. The name | |||
of each property is entered in the | |||
<code>PropNames.propertyNames</code> array of | |||
<code>String</code>s, and each has a unique integer constant | |||
defined, corresponding to the offset of the property name in | |||
that array. | |||
</p> | |||
<s3 title="Fields common to all classes"> | |||
<dl> | |||
<dt><code>final int dataTypes</code></dt> | |||
<dd> | |||
This field defines the allowable data types which may be | |||
assigned to the property. The value is chosen from the | |||
data type constants defined in <code>Properties</code>, and | |||
may consist of more than one of those constants, | |||
bit-ORed together. | |||
</dd> | |||
<dt><code>final int traitMapping</code></dt> | |||
<dd> | |||
This field defines the mapping of properties to traits | |||
in the <code>Area tree</code>. The value is chosen from the | |||
trait mapping constants defined in <code>Properties</code>, | |||
and may consist of more than one of those constants, | |||
bit-ORed together. | |||
</dd> | |||
<dt><code>final int initialValueType</code></dt> | |||
<dd> | |||
This field defines the data type of the initial value | |||
assigned to the property. The value is chosen from the | |||
initial value type constants defined in | |||
<code>Properties</code>. | |||
</dd> | |||
<dt><code>final int inherited</code></dt> | |||
<dd> | |||
This field defines the kind of inheritance applicable to | |||
the property. The value is chosen from the inheritance | |||
constants defined in <code>Properties</code>. | |||
</dd> | |||
</dl> | |||
</s3> | |||
<s3 title="Datatype dependent fields"> | |||
<dl> | |||
<dt>Enumeration types</dt> | |||
<dd> | |||
<strong><code>final String[] enums</code></strong><br/> | |||
This array contains the <code>NCName</code> text | |||
values of the enumeration. In the current | |||
implementation, it always contains a null value at | |||
<code>enum[0]</code>.<br/> <br/> | |||
<strong><code>final String[] | |||
enumValues</code></strong><br/> When the number of | |||
enumeration values is small, | |||
<code>enumValues</code> is a reference to the | |||
<code>enums</code> array.<br/> <br/> | |||
<strong><code>final String[] | |||
enumValues</code></strong><br/> When the number of | |||
enumeration values is small, | |||
<code>enumValues</code> is a reference to the | |||
<code>enums</code> array.<br/> <br/> | |||
<strong><code>final HashMap | |||
enumValues</code></strong><br/> When the number of | |||
enumeration values is larger, | |||
<code>enumValues</code> is a | |||
<code>HashMap</code> statically initialized to | |||
contain the integer constant values corresponding to | |||
each text value, indexed by the text | |||
value.<br/> <br/> | |||
<strong><code>final HashMap | |||
enumValues</code></strong><br/> When the number of | |||
enumeration values is larger, | |||
<code>enumValues</code> is a | |||
<code>HashMap</code> statically initialized to | |||
contain the integer constant values corresponding to | |||
each text value, indexed by the text | |||
value.<br/> <br/> | |||
<strong><code>final int</code></strong> | |||
<em><code>enumeration-constants</code></em><br/> A | |||
unique integer constant is defined for each of the | |||
possible enumeration values.<br/> <br/> | |||
</dd> | |||
<dt>Many types: | |||
<code>final</code> <em>datatype</em> | |||
<code>initialValue</code></dt> | |||
<dd> | |||
When the initial datatype does not have an implicit | |||
initial value (as, for example, does type | |||
<code>AUTO</code>) the initial value for the property is | |||
assigned to this field. The type of this field will | |||
vary according to the <code>initialValueType</code> | |||
field. | |||
</dd> | |||
<dt>AUTO: <code>PropertyValueList auto(property, | |||
list)></code></dt> | |||
<dd> | |||
When <em>AUTO</em> is a legal value type, the | |||
<code>auto()</code> method must be defined in the property | |||
class.<br/> | |||
<em>NOT YET IMPLEMENTED.</em> | |||
</dd> | |||
<dt>COMPLEX: <code>PropertyValueList complex(property, | |||
list)></code></dt> | |||
<dd> | |||
<em>COMPLEX</em> is specified as a value type when complex | |||
conditions apply to the selection of a value type, or | |||
when lists of values are acceptable. To process and | |||
validate such a property value assignment, the | |||
<code>complex()</code> method must be defined in the | |||
property class. | |||
</dd> | |||
</dl> | |||
</s3> | |||
<strong><code>final int</code></strong> | |||
<em><code>enumeration-constants</code></em><br/> A | |||
unique integer constant is defined for each of the | |||
possible enumeration values.<br/> <br/> | |||
</dd> | |||
<dt>Many types: | |||
<code>final</code> <em>datatype</em> | |||
<code>initialValue</code></dt> | |||
<dd> | |||
When the initial datatype does not have an implicit | |||
initial value (as, for example, does type | |||
<code>AUTO</code>) the initial value for the property is | |||
assigned to this field. The type of this field will | |||
vary according to the <code>initialValueType</code> | |||
field. | |||
</dd> | |||
<dt>AUTO: <code>PropertyValueList auto(property, | |||
list)></code></dt> | |||
<dd> | |||
When <em>AUTO</em> is a legal value type, the | |||
<code>auto()</code> method must be defined in the property | |||
class.<br/> | |||
<em>NOT YET IMPLEMENTED.</em> | |||
</dd> | |||
<dt>COMPLEX: <code>PropertyValueList complex(property, | |||
list)></code></dt> | |||
<dd> | |||
<em>COMPLEX</em> is specified as a value type when complex | |||
conditions apply to the selection of a value type, or | |||
when lists of values are acceptable. To process and | |||
validate such a property value assignment, the | |||
<code>complex()</code> method must be defined in the | |||
property class. | |||
</dd> | |||
</dl> | |||
</s3> | |||
</s2> | |||
<s2 title="Nested property pseudo-classes"> | |||
<p> | |||
The property pseudo-classes are classes, like | |||
<code>ColorCommon</code> which contain values, particularly | |||
<em>enums</em>, which are common to a number of actual | |||
properties. | |||
</p> | |||
<p> | |||
The property pseudo-classes are classes, like | |||
<code>ColorCommon</code> which contain values, particularly | |||
<em>enums</em>, which are common to a number of actual | |||
properties. | |||
</p> | |||
</s2> | |||
<p> | |||
<strong>Previous:</strong> <link href= "classes-overview.html" | |||
>property classes overview.</link> | |||
<strong>Previous:</strong> <link href= "classes-overview.html" | |||
>property classes overview.</link> | |||
</p> | |||
</s1> | |||
</body> |
@@ -15,214 +15,214 @@ | |||
<!-- one of (anchor s1) --> | |||
<s1 title="Property expression parsing"> | |||
<note> | |||
The following discussion of the experiments with alternate | |||
property expression parsing is very much a work in progress, | |||
and subject to sudden changes. | |||
The following discussion of the experiments with alternate | |||
property expression parsing is very much a work in progress, | |||
and subject to sudden changes. | |||
</note> | |||
<p> | |||
The parsing of property value expressions is handled by two | |||
closely related classes: <code>PropertyTokenizer</code> and its | |||
subclass, <code>PropertyParser</code>. | |||
<code>PropertyTokenizer</code>, as the name suggests, handles | |||
the tokenizing of the expression, handing <em>tokens</em> | |||
back to its subclass, | |||
<code>PropertyParser</code>. <code>PropertyParser</code>, in | |||
turn, returns a <code>PropertyValueList</code>, a list of | |||
<code>PropertyValue</code>s. | |||
The parsing of property value expressions is handled by two | |||
closely related classes: <code>PropertyTokenizer</code> and its | |||
subclass, <code>PropertyParser</code>. | |||
<code>PropertyTokenizer</code>, as the name suggests, handles | |||
the tokenizing of the expression, handing <em>tokens</em> | |||
back to its subclass, | |||
<code>PropertyParser</code>. <code>PropertyParser</code>, in | |||
turn, returns a <code>PropertyValueList</code>, a list of | |||
<code>PropertyValue</code>s. | |||
</p> | |||
<p> | |||
The tokenizer and parser rely in turn on the datatype | |||
definition from the <code>org.apache.fop.datatypes</code> | |||
package and the datatype <code>static final int</code> | |||
constants from <code>PropertyConsts</code>. | |||
The tokenizer and parser rely in turn on the datatype | |||
definition from the <code>org.apache.fop.datatypes</code> | |||
package and the datatype <code>static final int</code> | |||
constants from <code>PropertyConsts</code>. | |||
</p> | |||
<s2 title="Data types"> | |||
<p> | |||
The data types currently defined in | |||
<code>org.apache.fop.datatypes</code> include: | |||
</p> | |||
<table> | |||
<tr><th colspan="2">Numbers and lengths</th></tr> | |||
<tr> | |||
<th>Numeric</th> | |||
<td colspan="3"> | |||
The fundamental numeric data type. <em>Numerics</em> of | |||
various types are constructed by the classes listed | |||
below. | |||
</td> | |||
</tr> | |||
<tr> | |||
<td/> | |||
<th colspan="3">Constructor classes for <em>Numeric</em></th> | |||
</tr> | |||
<tr> | |||
<td/><td>Angle</td> | |||
<td colspan="2">In degrees(deg), gradients(grad) or | |||
radians(rad)</td> | |||
</tr> | |||
<tr> | |||
<td/><td>Ems</td> | |||
<td colspan="2">Relative length in <em>ems</em></td> | |||
</tr> | |||
<tr> | |||
<td/><td>Frequency</td> | |||
<td colspan="2">In hertz(Hz) or kilohertz(kHz)</td> | |||
</tr> | |||
<tr> | |||
<td/><td>IntegerType</td><td/> | |||
</tr> | |||
<tr> | |||
<td/><td>Length</td> | |||
<td colspan="2">In centimetres(cm), millimetres(mm), | |||
inches(in), points(pt), picas(pc) or pixels(px)</td> | |||
</tr> | |||
<tr> | |||
<td/><td>Percentage</td><td/> | |||
</tr> | |||
<tr> | |||
<td/><td>Time</td> | |||
<td>In seconds(s) or milliseconds(ms)</td> | |||
</tr> | |||
<tr><th colspan="2">Strings</th></tr> | |||
<tr> | |||
<th>StringType</th> | |||
<td colspan="3"> | |||
Base class for data types which result in a <em>String</em>. | |||
</td> | |||
</tr> | |||
<tr> | |||
<td/><th>Literal</th> | |||
<td colspan="2"> | |||
A subclass of <em>StringType</em> for literals which | |||
exceed the constraints of an <em>NCName</em>. | |||
</td> | |||
</tr> | |||
<tr> | |||
<td/><th>MimeType</th> | |||
<td colspan="2"> | |||
A subclass of <em>StringType</em> for literals which | |||
represent a mime type. | |||
</td> | |||
</tr> | |||
<tr> | |||
<td/><th>UriType</th> | |||
<td colspan="2"> | |||
A subclass of <em>StringType</em> for literals which | |||
represent a URI, as specified by the argument to | |||
<em>url()</em>. | |||
</td> | |||
</tr> | |||
<tr> | |||
<td/><th>NCName</th> | |||
<td colspan="2"> | |||
A subclass of <em>StringType</em> for literals which | |||
meet the constraints of an <em>NCName</em>. | |||
</td> | |||
</tr> | |||
<tr> | |||
<td/><td/><th>Country</th> | |||
<td>An RFC 3066/ISO 3166 country code.</td> | |||
</tr> | |||
<tr> | |||
<td/><td/><th>Language</th> | |||
<td>An RFC 3066/ISO 639 language code.</td> | |||
</tr> | |||
<tr> | |||
<td/><td/><th>Script</th> | |||
<td>An ISO 15924 script code.</td> | |||
</tr> | |||
<tr><th colspan="2">Enumerated types</th></tr> | |||
<tr> | |||
<th>EnumType</th> | |||
<td colspan="3"> | |||
An integer representing one of the tokens in a set of | |||
enumeration values. | |||
</td> | |||
</tr> | |||
<tr> | |||
<td/><th>MappedEnumType</th> | |||
<td colspan="2"> | |||
A subclass of <em>EnumType</em>. Maintains a | |||
<em>String</em> with the value to which the associated | |||
"raw" enumeration token maps. E.g., the | |||
<em>font-size</em> enumeration value "medium" maps to | |||
the <em>String</em> "12pt". | |||
</td> | |||
</tr> | |||
<tr><th colspan="2">Colors</th></tr> | |||
<tr> | |||
<th>ColorType</th> | |||
<td colspan="3"> | |||
Maintains a four-element array of float, derived from | |||
the name of a standard colour, the name returned by a | |||
call to <em>system-color()</em>, or an RGB | |||
specification. | |||
</td> | |||
</tr> | |||
<tr><th colspan="2">Fonts</th></tr> | |||
<tr> | |||
<th>FontFamilySet</th> | |||
<td colspan="3"> | |||
Maintains an array of <em>String</em>s containing a | |||
prioritized list of possibly generic font family names. | |||
</td> | |||
</tr> | |||
<tr><th colspan="2">Pseudo-types</th></tr> | |||
<tr> | |||
<td colspan="4"> | |||
A variety of pseudo-types have been defined as | |||
convenience types for frequently appearing enumeration | |||
token values, or for other special purposes. | |||
</td> | |||
</tr> | |||
<tr> | |||
<th>Inherit</th> | |||
<td colspan="3"> | |||
For values of <em>inherit</em>. | |||
</td> | |||
</tr> | |||
<tr> | |||
<th>Auto</th> | |||
<td colspan="3"> | |||
For values of <em>auto</em>. | |||
</td> | |||
</tr> | |||
<tr> | |||
<th>None</th> | |||
<td colspan="3"> | |||
For values of <em>none</em>. | |||
</td> | |||
</tr> | |||
<tr> | |||
<th>Bool</th> | |||
<td colspan="3"> | |||
For values of <em>true/false</em>. | |||
</td> | |||
</tr> | |||
<tr> | |||
<th>FromNearestSpecified</th> | |||
<td colspan="3"> | |||
Created to ensure that, when associated with | |||
a shorthand, the <em>from-nearest-specified-value()</em> | |||
core function is the sole component of the expression. | |||
</td> | |||
</tr> | |||
<tr> | |||
<th>FromParent</th> | |||
<td colspan="3"> | |||
Created to ensure that, when associated with | |||
a shorthand, the <em>from-parent()</em> | |||
core function is the sole component of the expression. | |||
</td> | |||
</tr> | |||
</table> | |||
<p> | |||
The data types currently defined in | |||
<code>org.apache.fop.datatypes</code> include: | |||
</p> | |||
<table> | |||
<tr><th colspan="2">Numbers and lengths</th></tr> | |||
<tr> | |||
<th>Numeric</th> | |||
<td colspan="3"> | |||
The fundamental numeric data type. <em>Numerics</em> of | |||
various types are constructed by the classes listed | |||
below. | |||
</td> | |||
</tr> | |||
<tr> | |||
<td/> | |||
<th colspan="3">Constructor classes for <em>Numeric</em></th> | |||
</tr> | |||
<tr> | |||
<td/><td>Angle</td> | |||
<td colspan="2">In degrees(deg), gradients(grad) or | |||
radians(rad)</td> | |||
</tr> | |||
<tr> | |||
<td/><td>Ems</td> | |||
<td colspan="2">Relative length in <em>ems</em></td> | |||
</tr> | |||
<tr> | |||
<td/><td>Frequency</td> | |||
<td colspan="2">In hertz(Hz) or kilohertz(kHz)</td> | |||
</tr> | |||
<tr> | |||
<td/><td>IntegerType</td><td/> | |||
</tr> | |||
<tr> | |||
<td/><td>Length</td> | |||
<td colspan="2">In centimetres(cm), millimetres(mm), | |||
inches(in), points(pt), picas(pc) or pixels(px)</td> | |||
</tr> | |||
<tr> | |||
<td/><td>Percentage</td><td/> | |||
</tr> | |||
<tr> | |||
<td/><td>Time</td> | |||
<td>In seconds(s) or milliseconds(ms)</td> | |||
</tr> | |||
<tr><th colspan="2">Strings</th></tr> | |||
<tr> | |||
<th>StringType</th> | |||
<td colspan="3"> | |||
Base class for data types which result in a <em>String</em>. | |||
</td> | |||
</tr> | |||
<tr> | |||
<td/><th>Literal</th> | |||
<td colspan="2"> | |||
A subclass of <em>StringType</em> for literals which | |||
exceed the constraints of an <em>NCName</em>. | |||
</td> | |||
</tr> | |||
<tr> | |||
<td/><th>MimeType</th> | |||
<td colspan="2"> | |||
A subclass of <em>StringType</em> for literals which | |||
represent a mime type. | |||
</td> | |||
</tr> | |||
<tr> | |||
<td/><th>UriType</th> | |||
<td colspan="2"> | |||
A subclass of <em>StringType</em> for literals which | |||
represent a URI, as specified by the argument to | |||
<em>url()</em>. | |||
</td> | |||
</tr> | |||
<tr> | |||
<td/><th>NCName</th> | |||
<td colspan="2"> | |||
A subclass of <em>StringType</em> for literals which | |||
meet the constraints of an <em>NCName</em>. | |||
</td> | |||
</tr> | |||
<tr> | |||
<td/><td/><th>Country</th> | |||
<td>An RFC 3066/ISO 3166 country code.</td> | |||
</tr> | |||
<tr> | |||
<td/><td/><th>Language</th> | |||
<td>An RFC 3066/ISO 639 language code.</td> | |||
</tr> | |||
<tr> | |||
<td/><td/><th>Script</th> | |||
<td>An ISO 15924 script code.</td> | |||
</tr> | |||
<tr><th colspan="2">Enumerated types</th></tr> | |||
<tr> | |||
<th>EnumType</th> | |||
<td colspan="3"> | |||
An integer representing one of the tokens in a set of | |||
enumeration values. | |||
</td> | |||
</tr> | |||
<tr> | |||
<td/><th>MappedEnumType</th> | |||
<td colspan="2"> | |||
A subclass of <em>EnumType</em>. Maintains a | |||
<em>String</em> with the value to which the associated | |||
"raw" enumeration token maps. E.g., the | |||
<em>font-size</em> enumeration value "medium" maps to | |||
the <em>String</em> "12pt". | |||
</td> | |||
</tr> | |||
<tr><th colspan="2">Colors</th></tr> | |||
<tr> | |||
<th>ColorType</th> | |||
<td colspan="3"> | |||
Maintains a four-element array of float, derived from | |||
the name of a standard colour, the name returned by a | |||
call to <em>system-color()</em>, or an RGB | |||
specification. | |||
</td> | |||
</tr> | |||
<tr><th colspan="2">Fonts</th></tr> | |||
<tr> | |||
<th>FontFamilySet</th> | |||
<td colspan="3"> | |||
Maintains an array of <em>String</em>s containing a | |||
prioritized list of possibly generic font family names. | |||
</td> | |||
</tr> | |||
<tr><th colspan="2">Pseudo-types</th></tr> | |||
<tr> | |||
<td colspan="4"> | |||
A variety of pseudo-types have been defined as | |||
convenience types for frequently appearing enumeration | |||
token values, or for other special purposes. | |||
</td> | |||
</tr> | |||
<tr> | |||
<th>Inherit</th> | |||
<td colspan="3"> | |||
For values of <em>inherit</em>. | |||
</td> | |||
</tr> | |||
<tr> | |||
<th>Auto</th> | |||
<td colspan="3"> | |||
For values of <em>auto</em>. | |||
</td> | |||
</tr> | |||
<tr> | |||
<th>None</th> | |||
<td colspan="3"> | |||
For values of <em>none</em>. | |||
</td> | |||
</tr> | |||
<tr> | |||
<th>Bool</th> | |||
<td colspan="3"> | |||
For values of <em>true/false</em>. | |||
</td> | |||
</tr> | |||
<tr> | |||
<th>FromNearestSpecified</th> | |||
<td colspan="3"> | |||
Created to ensure that, when associated with | |||
a shorthand, the <em>from-nearest-specified-value()</em> | |||
core function is the sole component of the expression. | |||
</td> | |||
</tr> | |||
<tr> | |||
<th>FromParent</th> | |||
<td colspan="3"> | |||
Created to ensure that, when associated with | |||
a shorthand, the <em>from-parent()</em> | |||
core function is the sole component of the expression. | |||
</td> | |||
</tr> | |||
</table> | |||
</s2> | |||
<s2 title="Tokenizer"> | |||
<p> | |||
The tokenizer returns one of the following token | |||
values: | |||
</p> | |||
<source> | |||
<p> | |||
The tokenizer returns one of the following token | |||
values: | |||
</p> | |||
<source> | |||
static final int | |||
EOF = 0 | |||
,NCNAME = 1 | |||
@@ -255,86 +255,86 @@ | |||
// never set as the end result of parsing a token. | |||
,NO_UNIT = 27 | |||
; | |||
</source> | |||
<p> | |||
Most of these tokens are self-explanatory, but a few need | |||
further comment. | |||
</p> | |||
<dl> | |||
<dt>AUTO</dt> | |||
<dd> | |||
Because of its frequency of occurrence, and the fact that | |||
it is always the <em>initial value</em> for any property | |||
which supports it, AUTO has been promoted into a | |||
pseudo-type with its on datatype class. Therefore, it is | |||
also reported as a token. | |||
</dd> | |||
<dt>NONE</dt> | |||
<dd> | |||
Similarly to AUTO, NONE has been promoted to a pseudo-type | |||
because of its frequency. | |||
</dd> | |||
<dt>BOOL</dt> | |||
<dd> | |||
There is a <em>de facto</em> boolean type buried in the | |||
enumeration types for many of the properties. It had been | |||
specified as a type in its own right in this code. | |||
</dd> | |||
<dt>MIMETYPE</dt> | |||
<dd> | |||
The property <code>content-type</code> introduces this | |||
complication. It can have two values of the form | |||
<strong>content-type:</strong><em>mime-type</em> | |||
(e.g. <code>content-type="content-type:xml/svg"</code>) or | |||
<strong>namespace-prefix:</strong><em>prefix</em> | |||
(e.g. <code>content-type="namespace-prefix:svg"</code>). The | |||
experimental code reduces these options to the payload | |||
in each case: an <code>NCName</code> in the case of a | |||
namespace prefix, and a MIMETYPE in the case of a | |||
content-type specification. <code>NCName</code>s cannot | |||
contain a "/". | |||
</dd> | |||
</dl> | |||
</source> | |||
<p> | |||
Most of these tokens are self-explanatory, but a few need | |||
further comment. | |||
</p> | |||
<dl> | |||
<dt>AUTO</dt> | |||
<dd> | |||
Because of its frequency of occurrence, and the fact that | |||
it is always the <em>initial value</em> for any property | |||
which supports it, AUTO has been promoted into a | |||
pseudo-type with its on datatype class. Therefore, it is | |||
also reported as a token. | |||
</dd> | |||
<dt>NONE</dt> | |||
<dd> | |||
Similarly to AUTO, NONE has been promoted to a pseudo-type | |||
because of its frequency. | |||
</dd> | |||
<dt>BOOL</dt> | |||
<dd> | |||
There is a <em>de facto</em> boolean type buried in the | |||
enumeration types for many of the properties. It had been | |||
specified as a type in its own right in this code. | |||
</dd> | |||
<dt>MIMETYPE</dt> | |||
<dd> | |||
The property <code>content-type</code> introduces this | |||
complication. It can have two values of the form | |||
<strong>content-type:</strong><em>mime-type</em> | |||
(e.g. <code>content-type="content-type:xml/svg"</code>) or | |||
<strong>namespace-prefix:</strong><em>prefix</em> | |||
(e.g. <code>content-type="namespace-prefix:svg"</code>). The | |||
experimental code reduces these options to the payload | |||
in each case: an <code>NCName</code> in the case of a | |||
namespace prefix, and a MIMETYPE in the case of a | |||
content-type specification. <code>NCName</code>s cannot | |||
contain a "/". | |||
</dd> | |||
</dl> | |||
</s2> | |||
<s2 title="Parser"> | |||
<p> | |||
The parser retuns a <code>PropertyValueList</code>, | |||
necessary because of the possibility that a list of | |||
<code>PropertyValue</code> elements may be returned from the | |||
expressions of soem properties. | |||
</p> | |||
<p> | |||
<code>PropertyValueList</code>s may contain | |||
<code>PropertyValue</code>s or other | |||
<code>PropertyValueList</code>s. This latter provision is | |||
necessitated for the peculiar case of of | |||
<em>text-shadow</em>, which may contain whitespace separated | |||
sublists of either two or three elements, separated from one | |||
another by commas. To accommodate this peculiarity, comma | |||
separated elements are added to the top-level list, while | |||
whitespace separated values are always collected into | |||
sublists to be added to the top-level list. | |||
</p> | |||
<p> | |||
Other special cases include the processing of the core | |||
functions <code>from-parent()</code> and | |||
<code>from-nearest-specified-value()</code> when these | |||
function calls are assigned to a shorthand property, or used | |||
with a shorthand property name as an argument. In these | |||
cases, the function call must be the sole component of the | |||
expression. The pseudo-element classes | |||
<code>FromParent</code> and | |||
<code>FromNearestSpecified</code> are generated in these | |||
circumstances so that an exception will be thrown if they | |||
are involved in expression evaluation with other | |||
components. (See Rec. Section 5.10.4 Property Value | |||
Functions.) | |||
</p> | |||
<p> | |||
The experimental code is a simple extension of the existing | |||
parser code, which itself borrowed heavily from James | |||
Clark's XT processor. | |||
</p> | |||
<p> | |||
The parser retuns a <code>PropertyValueList</code>, | |||
necessary because of the possibility that a list of | |||
<code>PropertyValue</code> elements may be returned from the | |||
expressions of soem properties. | |||
</p> | |||
<p> | |||
<code>PropertyValueList</code>s may contain | |||
<code>PropertyValue</code>s or other | |||
<code>PropertyValueList</code>s. This latter provision is | |||
necessitated for the peculiar case of of | |||
<em>text-shadow</em>, which may contain whitespace separated | |||
sublists of either two or three elements, separated from one | |||
another by commas. To accommodate this peculiarity, comma | |||
separated elements are added to the top-level list, while | |||
whitespace separated values are always collected into | |||
sublists to be added to the top-level list. | |||
</p> | |||
<p> | |||
Other special cases include the processing of the core | |||
functions <code>from-parent()</code> and | |||
<code>from-nearest-specified-value()</code> when these | |||
function calls are assigned to a shorthand property, or used | |||
with a shorthand property name as an argument. In these | |||
cases, the function call must be the sole component of the | |||
expression. The pseudo-element classes | |||
<code>FromParent</code> and | |||
<code>FromNearestSpecified</code> are generated in these | |||
circumstances so that an exception will be thrown if they | |||
are involved in expression evaluation with other | |||
components. (See Rec. Section 5.10.4 Property Value | |||
Functions.) | |||
</p> | |||
<p> | |||
The experimental code is a simple extension of the existing | |||
parser code, which itself borrowed heavily from James | |||
Clark's XT processor. | |||
</p> | |||
</s2> | |||
</s1> | |||
</body> |
@@ -15,162 +15,162 @@ | |||
<!-- one of (anchor s1) --> | |||
<s1 title="Keeps and space-specifiers in layout galleys"> | |||
<p> | |||
The <link href= "galleys.html" >layout galleys</link> and the | |||
<link href= "galleys.html#layout-tree" >layout tree</link> | |||
which is the context of this discussion have been discussed | |||
elsewhere. A <link href="keeps.html">previous document</link> | |||
discussed data structures which might facilitate the lining of | |||
blocks necessary to implement keeps. Here we discuss the | |||
similarities between the keep data structures and those | |||
required to implement space-specifier resolution. | |||
The <link href= "galleys.html" >layout galleys</link> and the | |||
<link href= "galleys.html#layout-tree" >layout tree</link> | |||
which is the context of this discussion have been discussed | |||
elsewhere. A <link href="keeps.html">previous document</link> | |||
discussed data structures which might facilitate the lining of | |||
blocks necessary to implement keeps. Here we discuss the | |||
similarities between the keep data structures and those | |||
required to implement space-specifier resolution. | |||
</p> | |||
<s2 title="Space-specifiers"> | |||
<note> | |||
<strong>4.3 Spaces and Conditionality</strong> | |||
... Space-specifiers occurring in sequence may interact with | |||
each other. The constraint imposed by a sequence of | |||
space-specifiers is computed by calculating for each | |||
space-specifier its associated resolved space-specifier in | |||
accordance with their conditionality and precedence. | |||
</note> | |||
<note> | |||
4.2.5 Stacking Constraints ... The intention of the | |||
definitions is to identify areas at any level of the tree | |||
which have only space between them. | |||
</note> | |||
<p> | |||
The quotations above are pivotal to understanding the | |||
complex discussion of spaces with which they are associated, | |||
all of which exists to enable the resolution of adjacent | |||
<space>s. It may be helpful to think of <em>stacking | |||
constraints</em> as <em><space>s interaction</em> or | |||
<em><space>s stacking interaction</em>. | |||
</p> | |||
<note> | |||
<strong>4.3 Spaces and Conditionality</strong> | |||
... Space-specifiers occurring in sequence may interact with | |||
each other. The constraint imposed by a sequence of | |||
space-specifiers is computed by calculating for each | |||
space-specifier its associated resolved space-specifier in | |||
accordance with their conditionality and precedence. | |||
</note> | |||
<note> | |||
4.2.5 Stacking Constraints ... The intention of the | |||
definitions is to identify areas at any level of the tree | |||
which have only space between them. | |||
</note> | |||
<p> | |||
The quotations above are pivotal to understanding the | |||
complex discussion of spaces with which they are associated, | |||
all of which exists to enable the resolution of adjacent | |||
<space>s. It may be helpful to think of <em>stacking | |||
constraints</em> as <em><space>s interaction</em> or | |||
<em><space>s stacking interaction</em>. | |||
</p> | |||
</s2> | |||
<s2 title="Block stacking constraints"> | |||
<p> | |||
In the discussion of block stacking constraints in Section | |||
4.2.5, the notion of <em>fence</em> is introduced. For | |||
block stacking constraints, a fence is defined as either a | |||
reference-area boundary or a non-zero padding or border | |||
specification. Fences, however, do not come into play | |||
when determining the constraint between siblings. (See | |||
<link href="#Figure1">Figure 1</link>.) | |||
</p> | |||
<p><strong>Figure 1</strong></p><anchor id="Figure1"/> | |||
<figure src="block-stacking-constraints.png" | |||
alt="block-stacking-constraints.png"/> | |||
<note> | |||
Figure 1 assumes a block-progression-direction of top to | |||
bottom. | |||
</note> | |||
<p> | |||
In <link href="#Figure1">Diagram a)</link>, block A has | |||
non-zero padding and borders, in addition to non-zero | |||
spaces. Note, however, that the space-after of A is | |||
adjacent to the space-before of block P, so borders and | |||
padding on these siblings have no impact on the interaction | |||
of their <space>s. The stacking constraint A,P is | |||
indicated by the red rectangle enclosing the space-after of | |||
A and the space-before of P. | |||
</p> | |||
<p> | |||
In <link href="#Figure1">Diagram b)</link>, block B is the | |||
first block child of P. The stacking constraint A,P is as | |||
before; the stacking constraint P,B is the space-before of | |||
B, as indicated by the enclosing magenta rectangle. In this | |||
case, however, the non-zero border of P prevents the | |||
interaction of the A,P and P,B stacking constraints. There | |||
is a <em>fence-before</em> P. The fence is notional; it has | |||
no precise location, as the diagram may lead one to believe. | |||
</p> | |||
<p> | |||
In <link href="#Figure1">Diagram c)</link>, because of the | |||
zero-width borders and padding on block P, the fence-before | |||
P is not present, and the adjacent <space>s of blocks | |||
A, P and B are free to interact. In this case, the stacking | |||
constraints A,P and P,B are as before, but now there is an | |||
additional stacking constraint A,B, represented by the light | |||
brown rectangle enclosing the other two stacking | |||
constraints. | |||
</p> | |||
<p> | |||
The other form of fence occurs when the parent block is a | |||
reference area. Diagram b) of <link href="#Figure2">Figure | |||
2</link> illustrates this situation. Block C is a | |||
reference-area, involving a 180 degree change of | |||
block-progression-direction (BPD). In the diagram, the | |||
inner edge of block C represents the content rectangle, with | |||
its changed BPD. The thicker outer edge represents the | |||
outer boundary of the padding, border and spaces of C. | |||
</p> | |||
<p> | |||
While not every reference-area will change the | |||
inline-progression-direction (IPD) and BPD of an area, no | |||
attempt is made to discriminate these cases. A | |||
reference-area always a fence. The fence comes into play in | |||
analogous circumstances to non-zero borders or padding. | |||
Space resolution between a reference area and its siblings | |||
is not affected. | |||
</p> | |||
<p> | |||
In the case of <link href="#Figure2">Diagram b)</link>, | |||
these are block stacking constraints B,C and C,A. Within | |||
the reference-area, bock stacing constraints C,D and E,C are | |||
unaffected. However, the fence prevents block stacking | |||
constraints such as B,E or D,A. When there is a change of | |||
BPD, as <link href="#Figure2">Diagram b)</link> makes | |||
visually obvious, it is difficult to imagine which blocks | |||
would have such a constraint, and what the ordering of the | |||
constraint would be. | |||
</p> | |||
<p><strong>Figure 2</strong></p> | |||
<anchor id="Figure2"/> | |||
<figure src="block-stacking-keeps.png" | |||
alt="block-stacking-keeps.png"/> | |||
<p> | |||
In the discussion of block stacking constraints in Section | |||
4.2.5, the notion of <em>fence</em> is introduced. For | |||
block stacking constraints, a fence is defined as either a | |||
reference-area boundary or a non-zero padding or border | |||
specification. Fences, however, do not come into play | |||
when determining the constraint between siblings. (See | |||
<link href="#Figure1">Figure 1</link>.) | |||
</p> | |||
<p><strong>Figure 1</strong></p><anchor id="Figure1"/> | |||
<figure src="block-stacking-constraints.png" | |||
alt="block-stacking-constraints.png"/> | |||
<note> | |||
Figure 1 assumes a block-progression-direction of top to | |||
bottom. | |||
</note> | |||
<p> | |||
In <link href="#Figure1">Diagram a)</link>, block A has | |||
non-zero padding and borders, in addition to non-zero | |||
spaces. Note, however, that the space-after of A is | |||
adjacent to the space-before of block P, so borders and | |||
padding on these siblings have no impact on the interaction | |||
of their <space>s. The stacking constraint A,P is | |||
indicated by the red rectangle enclosing the space-after of | |||
A and the space-before of P. | |||
</p> | |||
<p> | |||
In <link href="#Figure1">Diagram b)</link>, block B is the | |||
first block child of P. The stacking constraint A,P is as | |||
before; the stacking constraint P,B is the space-before of | |||
B, as indicated by the enclosing magenta rectangle. In this | |||
case, however, the non-zero border of P prevents the | |||
interaction of the A,P and P,B stacking constraints. There | |||
is a <em>fence-before</em> P. The fence is notional; it has | |||
no precise location, as the diagram may lead one to believe. | |||
</p> | |||
<p> | |||
In <link href="#Figure1">Diagram c)</link>, because of the | |||
zero-width borders and padding on block P, the fence-before | |||
P is not present, and the adjacent <space>s of blocks | |||
A, P and B are free to interact. In this case, the stacking | |||
constraints A,P and P,B are as before, but now there is an | |||
additional stacking constraint A,B, represented by the light | |||
brown rectangle enclosing the other two stacking | |||
constraints. | |||
</p> | |||
<p> | |||
The other form of fence occurs when the parent block is a | |||
reference area. Diagram b) of <link href="#Figure2">Figure | |||
2</link> illustrates this situation. Block C is a | |||
reference-area, involving a 180 degree change of | |||
block-progression-direction (BPD). In the diagram, the | |||
inner edge of block C represents the content rectangle, with | |||
its changed BPD. The thicker outer edge represents the | |||
outer boundary of the padding, border and spaces of C. | |||
</p> | |||
<p> | |||
While not every reference-area will change the | |||
inline-progression-direction (IPD) and BPD of an area, no | |||
attempt is made to discriminate these cases. A | |||
reference-area always a fence. The fence comes into play in | |||
analogous circumstances to non-zero borders or padding. | |||
Space resolution between a reference area and its siblings | |||
is not affected. | |||
</p> | |||
<p> | |||
In the case of <link href="#Figure2">Diagram b)</link>, | |||
these are block stacking constraints B,C and C,A. Within | |||
the reference-area, bock stacing constraints C,D and E,C are | |||
unaffected. However, the fence prevents block stacking | |||
constraints such as B,E or D,A. When there is a change of | |||
BPD, as <link href="#Figure2">Diagram b)</link> makes | |||
visually obvious, it is difficult to imagine which blocks | |||
would have such a constraint, and what the ordering of the | |||
constraint would be. | |||
</p> | |||
<p><strong>Figure 2</strong></p> | |||
<anchor id="Figure2"/> | |||
<figure src="block-stacking-keeps.png" | |||
alt="block-stacking-keeps.png"/> | |||
</s2> | |||
<s2 title="Keep relationships between blocks"> | |||
<p> | |||
As complicated as space-specifiers become when | |||
reference-areas are involved, the keep relationships as | |||
described in the <link | |||
href="keeps.html#Figure1">keeps</link> document, are | |||
unchanged. This is also illustrated in <link | |||
href="#Figure2">Figure 2</link>. Diagram b) shows the | |||
relative placement of blocks in the rendered output when a | |||
180 degree change of BPD occurs, with blocks D and E | |||
stacking in the reverse direction to blocks B and C. | |||
Diagram c) shows what happens when the page is too short to | |||
accommodate the last block. D is still laid out, but E is | |||
deferred to the next page. | |||
</p> | |||
<p> | |||
Note that this rendering reality is expressed directly in | |||
the area (and layout) tree view. Consequently, any keep | |||
relationships expressed as links threading through the | |||
layout tree will not need to be modified to account for | |||
reference-area boundaries, as is the case with similar | |||
space-specifier edge links. E.g., a keep-with-next | |||
condition on block B can be resolved along the path of these | |||
links (B->C->D) into a direct relationship of B->D, | |||
irrespective of the reference-area boundary. | |||
</p> | |||
<p> | |||
While the same relationships obviously hold when a reference | |||
area induces no change of BPD, the situation for BPD changes | |||
perpendicular to the parent's BPD may not be so clear. In | |||
general, it probably does not make much sense to impose keep | |||
conditions across such a boundary, but there seems to be | |||
nothing preventing such conditions. They can be dealt with | |||
in the same way, i.e., the next leaf block linked in area | |||
tree order must be the next laid out. If a keep condition | |||
is in place, an attempt must be made to meet it. A number | |||
of unusual considerations would apply, e.g. the minimum | |||
inline-progression-dimension of the first leaf block within | |||
the reference-area as compared to the minimum IPD of | |||
subsequent blocks, but <em>prima facie</em>, the essential | |||
logic of the keeps links remains. | |||
</p> | |||
<p> | |||
As complicated as space-specifiers become when | |||
reference-areas are involved, the keep relationships as | |||
described in the <link | |||
href="keeps.html#Figure1">keeps</link> document, are | |||
unchanged. This is also illustrated in <link | |||
href="#Figure2">Figure 2</link>. Diagram b) shows the | |||
relative placement of blocks in the rendered output when a | |||
180 degree change of BPD occurs, with blocks D and E | |||
stacking in the reverse direction to blocks B and C. | |||
Diagram c) shows what happens when the page is too short to | |||
accommodate the last block. D is still laid out, but E is | |||
deferred to the next page. | |||
</p> | |||
<p> | |||
Note that this rendering reality is expressed directly in | |||
the area (and layout) tree view. Consequently, any keep | |||
relationships expressed as links threading through the | |||
layout tree will not need to be modified to account for | |||
reference-area boundaries, as is the case with similar | |||
space-specifier edge links. E.g., a keep-with-next | |||
condition on block B can be resolved along the path of these | |||
links (B->C->D) into a direct relationship of B->D, | |||
irrespective of the reference-area boundary. | |||
</p> | |||
<p> | |||
While the same relationships obviously hold when a reference | |||
area induces no change of BPD, the situation for BPD changes | |||
perpendicular to the parent's BPD may not be so clear. In | |||
general, it probably does not make much sense to impose keep | |||
conditions across such a boundary, but there seems to be | |||
nothing preventing such conditions. They can be dealt with | |||
in the same way, i.e., the next leaf block linked in area | |||
tree order must be the next laid out. If a keep condition | |||
is in place, an attempt must be made to meet it. A number | |||
of unusual considerations would apply, e.g. the minimum | |||
inline-progression-dimension of the first leaf block within | |||
the reference-area as compared to the minimum IPD of | |||
subsequent blocks, but <em>prima facie</em>, the essential | |||
logic of the keeps links remains. | |||
</p> | |||
</s2> | |||
</s1> | |||
</body> |
@@ -29,7 +29,7 @@ | |||
<td> | |||
<link href= | |||
"http://www.w3.org/TR/xsl/slice4.html#area-common" | |||
>4.2.2 Common Traits</link><br/> | |||
>4.2.2 Common Traits</link><br/> | |||
<link href= | |||
"http://www.w3.org/TR/xsl/slice7.html#writing-mode" | |||
>7.27.7 writing-mode</link> | |||
@@ -108,7 +108,7 @@ | |||
>5.6 Non-property Based Trait Generation</link> | |||
</td> | |||
<td> | |||
Set "true" on:<br/> | |||
Set "true" on:<br/> | |||
simple-page-master<br/> | |||
title<br/> | |||
region-body<br/> | |||
@@ -121,7 +121,7 @@ | |||
table<br/> | |||
table-caption<br/> | |||
table-cell | |||
</td> | |||
</td> | |||
</tr> | |||
<tr> | |||
<td>is-viewport-area</td> | |||
@@ -232,7 +232,7 @@ | |||
<tr> | |||
<td>overline-score-color</td> | |||
<td></td> | |||
<td> | |||
<link href= | |||
"http://www.w3.org/TR/xsl/slice5.html#refine-text-decoration" | |||
@@ -249,7 +249,7 @@ | |||
<tr> | |||
<td>through-score</td> | |||
<td></td> | |||
<td> | |||
<link href= | |||
"http://www.w3.org/TR/xsl/slice5.html#refine-text-decoration" | |||
@@ -279,90 +279,90 @@ | |||
</link> | |||
</td> | |||
</tr> | |||
<tr> | |||
<th>Other Indirectly Derived Traits</th> | |||
</tr> | |||
<tr> | |||
<td>alignment-point</td> | |||
<td/> | |||
<td> | |||
<tr> | |||
<th>Other Indirectly Derived Traits</th> | |||
</tr> | |||
<tr> | |||
<td>alignment-point</td> | |||
<td/> | |||
<td> | |||
<link href= | |||
"http://www.w3.org/TR/xsl/slice4.html#area-intro" | |||
>4.1 Introduction</link> | |||
</td> | |||
</tr> | |||
<tr> | |||
<td>alignment-baseline</td> | |||
<td/> | |||
<td> | |||
</td> | |||
</tr> | |||
<tr> | |||
<td>alignment-baseline</td> | |||
<td/> | |||
<td> | |||
<link href= | |||
"http://www.w3.org/TR/xsl/slice4.html#area-intro" | |||
>4.1 Introduction</link> | |||
</td> | |||
</tr> | |||
<tr> | |||
<td>baseline-shift</td> | |||
<td/> | |||
<td> | |||
</td> | |||
</tr> | |||
<tr> | |||
<td>baseline-shift</td> | |||
<td/> | |||
<td> | |||
<link href= | |||
"http://www.w3.org/TR/xsl/slice4.html#area-intro" | |||
>4.1 Introduction</link> | |||
</td> | |||
</tr> | |||
<tr> | |||
<td>dominant-baseline-identifier</td> | |||
<td/> | |||
<td> | |||
</td> | |||
</tr> | |||
<tr> | |||
<td>dominant-baseline-identifier</td> | |||
<td/> | |||
<td> | |||
<link href= | |||
"http://www.w3.org/TR/xsl/slice4.html#area-intro" | |||
>4.1 Introduction</link> | |||
</td> | |||
</tr> | |||
<tr> | |||
<td>actual-baseline-table</td> | |||
<td/> | |||
<td> | |||
</td> | |||
</tr> | |||
<tr> | |||
<td>actual-baseline-table</td> | |||
<td/> | |||
<td> | |||
<link href= | |||
"http://www.w3.org/TR/xsl/slice4.html#area-intro" | |||
>4.1 Introduction</link> | |||
</td> | |||
</tr> | |||
<tr> | |||
<td>start-intrusion-adjustment</td> | |||
<td/> | |||
<td> | |||
</td> | |||
</tr> | |||
<tr> | |||
<td>start-intrusion-adjustment</td> | |||
<td/> | |||
<td> | |||
<link href= | |||
"http://www.w3.org/TR/xsl/slice4.html#area-intro" | |||
>4.1 Introduction</link> | |||
</td> | |||
</tr> | |||
<tr> | |||
<td>end-intrusion-adjustment</td> | |||
<td/> | |||
<td> | |||
</td> | |||
</tr> | |||
<tr> | |||
<td>end-intrusion-adjustment</td> | |||
<td/> | |||
<td> | |||
<link href= | |||
"http://www.w3.org/TR/xsl/slice4.html#area-intro" | |||
>4.1 Introduction</link> | |||
</td> | |||
</tr> | |||
<tr> | |||
<td>page-number</td> | |||
<td/> | |||
<td> | |||
</td> | |||
</tr> | |||
<tr> | |||
<td>page-number</td> | |||
<td/> | |||
<td> | |||
<link href= | |||
"http://www.w3.org/TR/xsl/slice4.html#area-intro" | |||
>4.1 Introduction</link> | |||
</td> | |||
</tr> | |||
<tr> | |||
<td>script</td> | |||
<td/> | |||
<td> | |||
</td> | |||
</tr> | |||
<tr> | |||
<td>script</td> | |||
<td/> | |||
<td> | |||
<link href= | |||
"http://www.w3.org/TR/xsl/slice4.html#area-intro" | |||
>4.1 Introduction</link> | |||
</td> | |||
</tr> | |||
</td> | |||
</tr> | |||
</table> | |||
</s1> | |||
</body> |
@@ -15,209 +15,209 @@ | |||
<!-- one of (anchor s1) --> | |||
<s1 title="An alternative parser integration"> | |||
<p> | |||
This note proposes an alternative method of integrating the | |||
output of the SAX parsing of the Flow Object (FO) tree into | |||
FOP processing. The pupose of the proposed changes is to | |||
provide for better decomposition of the process of analysing | |||
and rendering an fo tree such as is represented in the output | |||
from initial (XSLT) processing of an XML source document. | |||
This note proposes an alternative method of integrating the | |||
output of the SAX parsing of the Flow Object (FO) tree into | |||
FOP processing. The pupose of the proposed changes is to | |||
provide for better decomposition of the process of analysing | |||
and rendering an fo tree such as is represented in the output | |||
from initial (XSLT) processing of an XML source document. | |||
</p> | |||
<s2 title="Structure of SAX parsing"> | |||
<p> | |||
Figure 1 is a schematic representation of the process of SAX | |||
parsing of an input source. SAX parsing involves the | |||
registration, with an object implementing the | |||
<code>XMLReader</code> interface, of a | |||
<code>ContentHandler</code> which contains a callback | |||
routine for each of the event types encountered by the | |||
parser, e.g., <code>startDocument()</code>, | |||
<code>startElement()</code>, <code>characters()</code>, | |||
<code>endElement()</code> and <code>endDocument()</code>. | |||
Parsing is initiated by a call to the <code>parser()</code> | |||
method of the <code>XMLReader</code>. Note that the call to | |||
<code>parser()</code> and the calls to individual callback | |||
methods are synchronous: <code>parser()</code> will only | |||
return when the last callback method returns, and each | |||
callback must complete before the next is called.<br/><br/> | |||
<strong>Figure 1</strong> | |||
</p> | |||
<figure src="SAXParsing.png" alt="SAX parsing schematic"/> | |||
<p> | |||
In the process of parsing, the hierarchical structure of the | |||
original FO tree is flattened into a number of streams of | |||
events of the same type which are reported in the sequence | |||
in which they are encountered. Apart from that, the API | |||
imposes no structure or constraint which expresses the | |||
relationship between, e.g., a startElement event and the | |||
endElement event for the same element. To the extent that | |||
such relationship information is required, it must be | |||
managed by the callback routines. | |||
</p> | |||
<p> | |||
The most direct approach here is to build the tree | |||
"invisibly"; to bury within the callback routines the | |||
necessary code to construct the tree. In the simplest case, | |||
the whole of the FO tree is built within the call to | |||
<code>parser()</code>, and that in-memory tree is subsequently | |||
processed to (a) validate the FO structure, and (b) | |||
construct the Area tree. The problem with this approach is | |||
the potential size of the FO tree in memory. FOP has | |||
suffered from this problem in the past. | |||
</p> | |||
<p> | |||
Figure 1 is a schematic representation of the process of SAX | |||
parsing of an input source. SAX parsing involves the | |||
registration, with an object implementing the | |||
<code>XMLReader</code> interface, of a | |||
<code>ContentHandler</code> which contains a callback | |||
routine for each of the event types encountered by the | |||
parser, e.g., <code>startDocument()</code>, | |||
<code>startElement()</code>, <code>characters()</code>, | |||
<code>endElement()</code> and <code>endDocument()</code>. | |||
Parsing is initiated by a call to the <code>parser()</code> | |||
method of the <code>XMLReader</code>. Note that the call to | |||
<code>parser()</code> and the calls to individual callback | |||
methods are synchronous: <code>parser()</code> will only | |||
return when the last callback method returns, and each | |||
callback must complete before the next is called.<br/><br/> | |||
<strong>Figure 1</strong> | |||
</p> | |||
<figure src="SAXParsing.png" alt="SAX parsing schematic"/> | |||
<p> | |||
In the process of parsing, the hierarchical structure of the | |||
original FO tree is flattened into a number of streams of | |||
events of the same type which are reported in the sequence | |||
in which they are encountered. Apart from that, the API | |||
imposes no structure or constraint which expresses the | |||
relationship between, e.g., a startElement event and the | |||
endElement event for the same element. To the extent that | |||
such relationship information is required, it must be | |||
managed by the callback routines. | |||
</p> | |||
<p> | |||
The most direct approach here is to build the tree | |||
"invisibly"; to bury within the callback routines the | |||
necessary code to construct the tree. In the simplest case, | |||
the whole of the FO tree is built within the call to | |||
<code>parser()</code>, and that in-memory tree is subsequently | |||
processed to (a) validate the FO structure, and (b) | |||
construct the Area tree. The problem with this approach is | |||
the potential size of the FO tree in memory. FOP has | |||
suffered from this problem in the past. | |||
</p> | |||
</s2> | |||
<s2 title="Cluttered callbacks"> | |||
<p> | |||
On the other hand, the callback code may become increasingly | |||
complex as tree validation and the triggering of the Area | |||
tree processing and subsequent rendering is moved into the | |||
callbacks, typically the <code>endElement()</code> method. | |||
In order to overcome acute memory problems, the FOP code was | |||
recently modified in this way, to trigger Area tree building | |||
and rendering in the <code>endElement()</code> method, when | |||
the end of a page-sequence was detected. | |||
</p> | |||
<p> | |||
The drawback with such a method is that it becomes difficult | |||
to detemine the order of events and the circumstances in | |||
which any particular processing events are triggered. When | |||
the processing events are inherently self-contained, this is | |||
irrelevant. But the more complex and context-dependent the | |||
relationships are among the processing elements, the more | |||
obscurity is engendered in the code by such "side-effect" | |||
processing. | |||
</p> | |||
<p> | |||
On the other hand, the callback code may become increasingly | |||
complex as tree validation and the triggering of the Area | |||
tree processing and subsequent rendering is moved into the | |||
callbacks, typically the <code>endElement()</code> method. | |||
In order to overcome acute memory problems, the FOP code was | |||
recently modified in this way, to trigger Area tree building | |||
and rendering in the <code>endElement()</code> method, when | |||
the end of a page-sequence was detected. | |||
</p> | |||
<p> | |||
The drawback with such a method is that it becomes difficult | |||
to detemine the order of events and the circumstances in | |||
which any particular processing events are triggered. When | |||
the processing events are inherently self-contained, this is | |||
irrelevant. But the more complex and context-dependent the | |||
relationships are among the processing elements, the more | |||
obscurity is engendered in the code by such "side-effect" | |||
processing. | |||
</p> | |||
</s2> | |||
<s2 title="From passive to active parsing"> | |||
<p> | |||
In order to solve the simultaneous problems of exposing the | |||
structure of the processing and minimising in-memory | |||
requirements, the experimental code separates the parsing of | |||
the input source from the building of the FO tree and all | |||
downstream processing. The callback routines become | |||
minimal, consisting of the creation and buffering of | |||
<code>XMLEvent</code> objects as a <em>producer</em>. All | |||
of these objects are effectively merged into a single event | |||
stream, in strict event order, for subsequent access by the | |||
FO tree building process, acting as a | |||
<em>consumer</em>. In itself, this does not reduce the | |||
footprint. This occurs when the approach is generalised to | |||
modularise FOP processing.<br/><br/> <strong>Figure 2</strong> | |||
</p> | |||
<figure src="XML-event-buffer.png" alt="XML event buffer"/> | |||
<p> | |||
The most useful change that this brings about is the switch | |||
from <em>passive</em> to <em>active</em> XML element | |||
processing. The process of parsing now becomes visible to | |||
the controlling process. All local validation requirements, | |||
all object and data structure building, is initiated by the | |||
process(es) <em>get</em>ting from the queue - in the case | |||
above, the FO tree builder. | |||
</p> | |||
<p> | |||
In order to solve the simultaneous problems of exposing the | |||
structure of the processing and minimising in-memory | |||
requirements, the experimental code separates the parsing of | |||
the input source from the building of the FO tree and all | |||
downstream processing. The callback routines become | |||
minimal, consisting of the creation and buffering of | |||
<code>XMLEvent</code> objects as a <em>producer</em>. All | |||
of these objects are effectively merged into a single event | |||
stream, in strict event order, for subsequent access by the | |||
FO tree building process, acting as a | |||
<em>consumer</em>. In itself, this does not reduce the | |||
footprint. This occurs when the approach is generalised to | |||
modularise FOP processing.<br/><br/> <strong>Figure 2</strong> | |||
</p> | |||
<figure src="XML-event-buffer.png" alt="XML event buffer"/> | |||
<p> | |||
The most useful change that this brings about is the switch | |||
from <em>passive</em> to <em>active</em> XML element | |||
processing. The process of parsing now becomes visible to | |||
the controlling process. All local validation requirements, | |||
all object and data structure building, is initiated by the | |||
process(es) <em>get</em>ting from the queue - in the case | |||
above, the FO tree builder. | |||
</p> | |||
</s2> | |||
<s2 title="XMLEvent methods"> | |||
<anchor id="XMLEvent-methods"/> | |||
<p> | |||
The experimental code uses a class <strong>XMLEvent</strong> | |||
to provide the objects which are placed in the queue. | |||
<em>XMLEvent</em> includes a variety of methods to access | |||
elements in the queue. Namespace URIs encountered in | |||
parsing are maintined in a <code>static</code> | |||
<code>HashMap</code> where they are associated with a unique | |||
integer index. This integer value is used in the signature | |||
of some of the access methods. | |||
</p> | |||
<dl> | |||
<dt>XMLEvent getEvent(SyncedCircularBuffer events)</dt> | |||
<dd> | |||
This is the basis of all of the queue access methods. It | |||
returns the next element from the queue, which may be a | |||
pushback element. | |||
</dd> | |||
<dt>XMLEvent getEndDocument(events)</dt> | |||
<dd> | |||
<em>get</em> and discard elements from the queue | |||
until an ENDDOCUMENT element is found and returned. | |||
</dd> | |||
<dt> XMLEvent expectEndDocument(events)</dt> | |||
<dd> | |||
If the next element on the queue is an ENDDOCUMENT event, | |||
return it. Otherwise, push the element back and throw an | |||
exception. Each of the <em>get</em> methods (except | |||
<em>getEvent()</em> itself) has a corresponding | |||
<em>expect</em> method. | |||
</dd> | |||
<dt>XMLEvent get/expectStartElement(events)</dt> | |||
<dd> Return the next STARTELEMENT event from the queue.</dd> | |||
<dt>XMLEvent get/expectStartElement(events, String | |||
qName)</dt> | |||
<dd> | |||
Return the next STARTELEMENT with a QName matching | |||
<em>qName</em>. | |||
</dd> | |||
<dt> | |||
XMLEvent get/expectStartElement(events, int uriIndex, | |||
String localName) | |||
</dt> | |||
<dd> | |||
Return the next STARTELEMENT with a URI indicated by the | |||
<em>uriIndex</em> and a local name matching <em>localName</em>. | |||
</dd> | |||
<dt> | |||
XMLEvent get/expectStartElement(events, LinkedList list) | |||
</dt> | |||
<dd> | |||
<em>list</em> contains instances of the nested class | |||
<code>UriLocalName</code>, which hold a | |||
<em>uriIndex</em> and a <em>localName</em>. Return | |||
the next STARTELEMENT with a URI indicated by the | |||
<em>uriIndex</em> and a local name matching | |||
<em>localName</em> from any element of | |||
<em>list</em>. | |||
</dd> | |||
<dt>XMLEvent get/expectEndElement(events)</dt> | |||
<dd>Return the next ENDELEMENT.</dd> | |||
<dt>XMLEvent get/expectEndElement(events, qName)</dt> | |||
<dd>Return the next ENDELEMENT with QName | |||
<em>qname</em>.</dd> | |||
<dt>XMLEvent get/expectEndElement(events, uriIndex, localName)</dt> | |||
<dd> | |||
Return the next ENDELEMENT with a URI indicated by the | |||
<em>uriIndex</em> and a local name matching | |||
<em>localName</em>. | |||
</dd> | |||
<dt> | |||
XMLEvent get/expectEndElement(events, XMLEvent event) | |||
</dt> | |||
<dd> | |||
Return the next ENDELEMENT with a URI matching the | |||
<em>uriIndex</em> and <em>localName</em> | |||
matching those in the <em>event</em> argument. This | |||
is intended as a quick way to find the ENDELEMENT matching | |||
a previously returned STARTELEMENT. | |||
</dd> | |||
<dt>XMLEvent get/expectCharacters(events)</dt> | |||
<dd>Return the next CHARACTERS event.</dd> | |||
</dl> | |||
<anchor id="XMLEvent-methods"/> | |||
<p> | |||
The experimental code uses a class <strong>XMLEvent</strong> | |||
to provide the objects which are placed in the queue. | |||
<em>XMLEvent</em> includes a variety of methods to access | |||
elements in the queue. Namespace URIs encountered in | |||
parsing are maintined in a <code>static</code> | |||
<code>HashMap</code> where they are associated with a unique | |||
integer index. This integer value is used in the signature | |||
of some of the access methods. | |||
</p> | |||
<dl> | |||
<dt>XMLEvent getEvent(SyncedCircularBuffer events)</dt> | |||
<dd> | |||
This is the basis of all of the queue access methods. It | |||
returns the next element from the queue, which may be a | |||
pushback element. | |||
</dd> | |||
<dt>XMLEvent getEndDocument(events)</dt> | |||
<dd> | |||
<em>get</em> and discard elements from the queue | |||
until an ENDDOCUMENT element is found and returned. | |||
</dd> | |||
<dt> XMLEvent expectEndDocument(events)</dt> | |||
<dd> | |||
If the next element on the queue is an ENDDOCUMENT event, | |||
return it. Otherwise, push the element back and throw an | |||
exception. Each of the <em>get</em> methods (except | |||
<em>getEvent()</em> itself) has a corresponding | |||
<em>expect</em> method. | |||
</dd> | |||
<dt>XMLEvent get/expectStartElement(events)</dt> | |||
<dd> Return the next STARTELEMENT event from the queue.</dd> | |||
<dt>XMLEvent get/expectStartElement(events, String | |||
qName)</dt> | |||
<dd> | |||
Return the next STARTELEMENT with a QName matching | |||
<em>qName</em>. | |||
</dd> | |||
<dt> | |||
XMLEvent get/expectStartElement(events, int uriIndex, | |||
String localName) | |||
</dt> | |||
<dd> | |||
Return the next STARTELEMENT with a URI indicated by the | |||
<em>uriIndex</em> and a local name matching <em>localName</em>. | |||
</dd> | |||
<dt> | |||
XMLEvent get/expectStartElement(events, LinkedList list) | |||
</dt> | |||
<dd> | |||
<em>list</em> contains instances of the nested class | |||
<code>UriLocalName</code>, which hold a | |||
<em>uriIndex</em> and a <em>localName</em>. Return | |||
the next STARTELEMENT with a URI indicated by the | |||
<em>uriIndex</em> and a local name matching | |||
<em>localName</em> from any element of | |||
<em>list</em>. | |||
</dd> | |||
<dt>XMLEvent get/expectEndElement(events)</dt> | |||
<dd>Return the next ENDELEMENT.</dd> | |||
<dt>XMLEvent get/expectEndElement(events, qName)</dt> | |||
<dd>Return the next ENDELEMENT with QName | |||
<em>qname</em>.</dd> | |||
<dt>XMLEvent get/expectEndElement(events, uriIndex, localName)</dt> | |||
<dd> | |||
Return the next ENDELEMENT with a URI indicated by the | |||
<em>uriIndex</em> and a local name matching | |||
<em>localName</em>. | |||
</dd> | |||
<dt> | |||
XMLEvent get/expectEndElement(events, XMLEvent event) | |||
</dt> | |||
<dd> | |||
Return the next ENDELEMENT with a URI matching the | |||
<em>uriIndex</em> and <em>localName</em> | |||
matching those in the <em>event</em> argument. This | |||
is intended as a quick way to find the ENDELEMENT matching | |||
a previously returned STARTELEMENT. | |||
</dd> | |||
<dt>XMLEvent get/expectCharacters(events)</dt> | |||
<dd>Return the next CHARACTERS event.</dd> | |||
</dl> | |||
</s2> | |||
<s2 title="FOP modularisation"> | |||
<p> | |||
This same principle can be extended to the other major | |||
sub-systems of FOP processing. In each case, while it is | |||
possible to hold a complete intermediate result in memory, | |||
the memory costs of that approach are too high. The | |||
sub-systems - xml parsing, FO tree construction, Area tree | |||
construction and rendering - must run in parallel if the | |||
footprint is to be kept manageable. By creating a series of | |||
producer-consumer pairs linked by synchronized buffers, | |||
logical isolation can be achieved while rates of processing | |||
remain coupled. By introducing feedback loops conveying | |||
information about the completion of processing of the | |||
elements, sub-systems can dispose of or precis those | |||
elements without having to be tightly coupled to downstream | |||
processes.<br/><br/> | |||
<strong>Figure 3</strong> | |||
</p> | |||
<figure src="processPlumbing.png" alt="FOP modularisation"/> | |||
<p> | |||
This same principle can be extended to the other major | |||
sub-systems of FOP processing. In each case, while it is | |||
possible to hold a complete intermediate result in memory, | |||
the memory costs of that approach are too high. The | |||
sub-systems - xml parsing, FO tree construction, Area tree | |||
construction and rendering - must run in parallel if the | |||
footprint is to be kept manageable. By creating a series of | |||
producer-consumer pairs linked by synchronized buffers, | |||
logical isolation can be achieved while rates of processing | |||
remain coupled. By introducing feedback loops conveying | |||
information about the completion of processing of the | |||
elements, sub-systems can dispose of or precis those | |||
elements without having to be tightly coupled to downstream | |||
processes.<br/><br/> | |||
<strong>Figure 3</strong> | |||
</p> | |||
<figure src="processPlumbing.png" alt="FOP modularisation"/> | |||
</s2> | |||
</s1> | |||
</body> |
@@ -1,48 +1,48 @@ | |||
<?xml version="1.0" standalone="no"?> | |||
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20001102//EN" | |||
"http://www.w3.org/TR/2000/CR-SVG-20001102/DTD/svg-20001102.dtd"> | |||
"http://www.w3.org/TR/2000/CR-SVG-20001102/DTD/svg-20001102.dtd"> | |||
<svg width="420" height="300"> | |||
<defs> | |||
<marker id="measure" viewBox="0 0 10 10" refX="0" refY="5" markerWidth="4" | |||
markerHeight="3" orient="auto"> | |||
<path d="M0 0 L5 10 L10 0 z"/> | |||
<path d="M0 10 L10 10 L10 9 L0 9 z"/> | |||
</marker> | |||
</defs> | |||
<rect x="12" y="-29" width="307" height="371" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(0,0,0); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="12" y="19" width="307" height="170" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(58,53,255); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="13" y="201" width="307" height="126" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(33,75,255); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="13" y="71" width="140" height="202" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(255,169,33); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<path d="M11.5 219 L320.5 219" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-linecap:round;stroke-width:1;stroke-opacity:1; | |||
stroke:rgb(36,239,21);fill-opacity:1;fill:rgb(0,0,0);opacity:1"/> | |||
<text x="0" y="216" style="font-family:Arial;font-size:12;stroke-width:1;stroke-opacity:1;stroke:rgb(0,0,0); | |||
fill-opacity:1;fill:rgb(0,0,0);opacity:1">flow limit</text> | |||
<text x="72" y="139" style="font-family:Arial;font-size:12;stroke-width:1;stroke-opacity:1;stroke:rgb(0,0,0); | |||
fill-opacity:1;fill:rgb(0,0,0);opacity:1">float</text> | |||
<text x="337.565" y="144" style="font-family:Arial;font-size:12;stroke-width:1;stroke-opacity:1;stroke:rgb(0,0,0); | |||
fill-opacity:1;fill:rgb(0,0,0);opacity:1">effective height</text> | |||
<path d="M330.5 63 L330.5 271" style="marker-end:url(#measure);marker-start:url(#measure);stroke-miterlimit:4;stroke-linejoin:miter; | |||
stroke-linecap:round;stroke-width:1;stroke-opacity:1;stroke:rgb(0,0,0);fill-opacity:1; | |||
fill:rgb(0,0,0);opacity:1"/> | |||
<text x="349" y="157" style="font-family:Arial;font-size:12;stroke-width:1;stroke-opacity:1;stroke:rgb(0,0,0); | |||
fill-opacity:1;fill:rgb(0,0,0);opacity:1">of float line</text> | |||
<rect x="12" y="18" width="306" height="22" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(166,166,166); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="12" y="45" width="306" height="20" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(166,166,166); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="154" y="72" width="164" height="16" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(166,166,166); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="153" y="97" width="166" height="15" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(166,166,166); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="154" y="123" width="132" height="16" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(166,166,166); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="220" y="71" width="6" height="17" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(247,255,9); | |||
fill-opacity:1;fill:rgb(255,255,0);opacity:1"/> | |||
<text x="232" y="91" style="font-family:Arial;font-size:12;stroke-width:1;stroke-opacity:1;stroke:rgb(0,0,0); | |||
fill-opacity:1;fill:rgb(0,0,0);opacity:1">float anchor</text> | |||
<defs> | |||
<marker id="measure" viewBox="0 0 10 10" refX="0" refY="5" markerWidth="4" | |||
markerHeight="3" orient="auto"> | |||
<path d="M0 0 L5 10 L10 0 z"/> | |||
<path d="M0 10 L10 10 L10 9 L0 9 z"/> | |||
</marker> | |||
</defs> | |||
<rect x="12" y="-29" width="307" height="371" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(0,0,0); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="12" y="19" width="307" height="170" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(58,53,255); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="13" y="201" width="307" height="126" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(33,75,255); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="13" y="71" width="140" height="202" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(255,169,33); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<path d="M11.5 219 L320.5 219" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-linecap:round;stroke-width:1;stroke-opacity:1; | |||
stroke:rgb(36,239,21);fill-opacity:1;fill:rgb(0,0,0);opacity:1"/> | |||
<text x="0" y="216" style="font-family:Arial;font-size:12;stroke-width:1;stroke-opacity:1;stroke:rgb(0,0,0); | |||
fill-opacity:1;fill:rgb(0,0,0);opacity:1">flow limit</text> | |||
<text x="72" y="139" style="font-family:Arial;font-size:12;stroke-width:1;stroke-opacity:1;stroke:rgb(0,0,0); | |||
fill-opacity:1;fill:rgb(0,0,0);opacity:1">float</text> | |||
<text x="337.565" y="144" style="font-family:Arial;font-size:12;stroke-width:1;stroke-opacity:1;stroke:rgb(0,0,0); | |||
fill-opacity:1;fill:rgb(0,0,0);opacity:1">effective height</text> | |||
<path d="M330.5 63 L330.5 271" style="marker-end:url(#measure);marker-start:url(#measure);stroke-miterlimit:4;stroke-linejoin:miter; | |||
stroke-linecap:round;stroke-width:1;stroke-opacity:1;stroke:rgb(0,0,0);fill-opacity:1; | |||
fill:rgb(0,0,0);opacity:1"/> | |||
<text x="349" y="157" style="font-family:Arial;font-size:12;stroke-width:1;stroke-opacity:1;stroke:rgb(0,0,0); | |||
fill-opacity:1;fill:rgb(0,0,0);opacity:1">of float line</text> | |||
<rect x="12" y="18" width="306" height="22" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(166,166,166); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="12" y="45" width="306" height="20" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(166,166,166); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="154" y="72" width="164" height="16" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(166,166,166); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="153" y="97" width="166" height="15" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(166,166,166); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="154" y="123" width="132" height="16" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(166,166,166); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="220" y="71" width="6" height="17" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(247,255,9); | |||
fill-opacity:1;fill:rgb(255,255,0);opacity:1"/> | |||
<text x="232" y="91" style="font-family:Arial;font-size:12;stroke-width:1;stroke-opacity:1;stroke:rgb(0,0,0); | |||
fill-opacity:1;fill:rgb(0,0,0);opacity:1">float anchor</text> | |||
</svg> | |||
@@ -72,289 +72,289 @@ parent. | |||
The Name, Spec Content, and Breaks & Keeps information is definite. | |||
The type and multiplicity of generated areas is definite, as well as whether | |||
the generated areas are reference areas or not. The BaseClass and the | |||
layout area information is FOP-implementation dependent. | |||
layout area information is FOP-implementation dependent. | |||
</para> | |||
<para><em>Note:</em> Numbers in parentheses refer to Notes. A * after | |||
an FO name indicates that the object is not yet implemented.</para> | |||
</usage> | |||
<category class="block-level"> | |||
<object> | |||
<name>block</name> | |||
<baseClass>FObjMixed</baseClass> | |||
<specContent><![CDATA[(#PCDATA|%inline;|%block;)*]]></specContent> | |||
<generatedAreas> | |||
<type><class>normal</class><stacking>block</stacking></type> | |||
<multiplicity>1..*</multiplicity> | |||
<currentLayout>BlockArea</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>All (2)</breaksKeeps> | |||
<name>block</name> | |||
<baseClass>FObjMixed</baseClass> | |||
<specContent><![CDATA[(#PCDATA|%inline;|%block;)*]]></specContent> | |||
<generatedAreas> | |||
<type><class>normal</class><stacking>block</stacking></type> | |||
<multiplicity>1..*</multiplicity> | |||
<currentLayout>BlockArea</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>All (2)</breaksKeeps> | |||
</object> | |||
<object> | |||
<name>block-container</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent><![CDATA[(%block;)+]]></specContent> | |||
<generatedAreas isReference="true"> | |||
<type><class>viewport/ref</class><stacking>block</stacking></type> | |||
<multiplicity>1..*</multiplicity> | |||
<currentLayout>AreaContainer</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>All</breaksKeeps> | |||
<name>block-container</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent><![CDATA[(%block;)+]]></specContent> | |||
<generatedAreas isReference="true"> | |||
<type><class>viewport/ref</class><stacking>block</stacking></type> | |||
<multiplicity>1..*</multiplicity> | |||
<currentLayout>AreaContainer</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>All</breaksKeeps> | |||
</object> | |||
<object implemented="false"> | |||
<name>table-and-caption</name> | |||
<baseClass>FObj (1)</baseClass> | |||
<specContent>(table-caption?,table)</specContent> | |||
<generatedAreas> | |||
<type><class>normal</class><stacking>block</stacking></type> | |||
<multiplicity>1..*</multiplicity> | |||
<currentLayout>AreaContainer</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>All keeps</breaksKeeps> | |||
<name>table-and-caption</name> | |||
<baseClass>FObj (1)</baseClass> | |||
<specContent>(table-caption?,table)</specContent> | |||
<generatedAreas> | |||
<type><class>normal</class><stacking>block</stacking></type> | |||
<multiplicity>1..*</multiplicity> | |||
<currentLayout>AreaContainer</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>All keeps</breaksKeeps> | |||
</object> | |||
<object> | |||
<name>table</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent>(table-column*,table-header?, table-footer?,table-body+)</specContent> | |||
<generatedAreas isReference="true"> | |||
<type><class>normal</class><stacking>block</stacking></type> | |||
<multiplicity>1..*</multiplicity> | |||
<currentLayout>AreaContainer</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>All</breaksKeeps> | |||
<name>table</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent>(table-column*,table-header?, table-footer?,table-body+)</specContent> | |||
<generatedAreas isReference="true"> | |||
<type><class>normal</class><stacking>block</stacking></type> | |||
<multiplicity>1..*</multiplicity> | |||
<currentLayout>AreaContainer</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>All</breaksKeeps> | |||
</object> | |||
<object> | |||
<name>list-block</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent>(list-item+)</specContent> | |||
<generatedAreas> | |||
<type><class>normal</class><stacking>block</stacking></type> | |||
<multiplicity>1..*</multiplicity> | |||
<currentLayout>BlockArea</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>All</breaksKeeps> | |||
<name>list-block</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent>(list-item+)</specContent> | |||
<generatedAreas> | |||
<type><class>normal</class><stacking>block</stacking></type> | |||
<multiplicity>1..*</multiplicity> | |||
<currentLayout>BlockArea</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>All</breaksKeeps> | |||
</object> | |||
</category> | |||
<category class="inline-level"> | |||
<object implemented="false"> | |||
<name>bidi-override</name> | |||
<baseClass>FObjMixed (1)</baseClass> | |||
<specContent><![CDATA[(#PCDATA|%inline;|%block;)*]]></specContent> | |||
<generatedAreas> | |||
<type><class>normal</class><stacking>inline</stacking></type> | |||
<multiplicity>1..*</multiplicity> | |||
<currentLayout/> | |||
</generatedAreas> | |||
<breaksKeeps/> | |||
<name>bidi-override</name> | |||
<baseClass>FObjMixed (1)</baseClass> | |||
<specContent><![CDATA[(#PCDATA|%inline;|%block;)*]]></specContent> | |||
<generatedAreas> | |||
<type><class>normal</class><stacking>inline</stacking></type> | |||
<multiplicity>1..*</multiplicity> | |||
<currentLayout/> | |||
</generatedAreas> | |||
<breaksKeeps/> | |||
</object> | |||
<object> | |||
<name>character</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent>EMPTY</specContent> | |||
<generatedAreas> | |||
<type><class>normal</class><stacking>inline</stacking></type> | |||
<multiplicity>1</multiplicity> | |||
<currentLayout intoParentArea="true">BlockArea</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>kwn, kwp</breaksKeeps> | |||
<name>character</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent>EMPTY</specContent> | |||
<generatedAreas> | |||
<type><class>normal</class><stacking>inline</stacking></type> | |||
<multiplicity>1</multiplicity> | |||
<currentLayout intoParentArea="true">BlockArea</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>kwn, kwp</breaksKeeps> | |||
</object> | |||
<object> | |||
<name>external-graphic</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent>EMPTY</specContent> | |||
<generatedAreas> | |||
<type><class>viewport/ref</class><stacking>inline</stacking></type> | |||
<multiplicity>1</multiplicity> | |||
<currentLayout>ImageArea</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>kwn, kwp</breaksKeeps> | |||
<name>external-graphic</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent>EMPTY</specContent> | |||
<generatedAreas> | |||
<type><class>viewport/ref</class><stacking>inline</stacking></type> | |||
<multiplicity>1</multiplicity> | |||
<currentLayout>ImageArea</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>kwn, kwp</breaksKeeps> | |||
</object> | |||
<object implemented="false"> | |||
<name>initial-property-set</name> | |||
<baseClass>FObj (1)</baseClass> | |||
<specContent>EMPTY</specContent> | |||
<generatedAreas/> | |||
<breaksKeeps/> | |||
<name>initial-property-set</name> | |||
<baseClass>FObj (1)</baseClass> | |||
<specContent>EMPTY</specContent> | |||
<generatedAreas/> | |||
<breaksKeeps/> | |||
</object> | |||
<object> | |||
<name>instream-foreign-object</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent>XML</specContent> | |||
<generatedAreas> | |||
<type><class>viewport/ref</class><stacking>inline</stacking></type> | |||
<multiplicity>1</multiplicity> | |||
<currentLayout>ForeignObjectArea</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>kwn, kwp</breaksKeeps> | |||
<name>instream-foreign-object</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent>XML</specContent> | |||
<generatedAreas> | |||
<type><class>viewport/ref</class><stacking>inline</stacking></type> | |||
<multiplicity>1</multiplicity> | |||
<currentLayout>ForeignObjectArea</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>kwn, kwp</breaksKeeps> | |||
</object> | |||
<object> | |||
<name>inline</name> | |||
<baseClass>FObjMixed</baseClass> | |||
<specContent><![CDATA[(#PCDATA|%inline;|%block;)*]]></specContent> | |||
<generatedAreas> | |||
<type><class>normal</class><stacking>inline</stacking></type> | |||
<multiplicity>1..*</multiplicity> | |||
<currentLayout intoParentArea="true">Area</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>All keeps</breaksKeeps> | |||
<name>inline</name> | |||
<baseClass>FObjMixed</baseClass> | |||
<specContent><![CDATA[(#PCDATA|%inline;|%block;)*]]></specContent> | |||
<generatedAreas> | |||
<type><class>normal</class><stacking>inline</stacking></type> | |||
<multiplicity>1..*</multiplicity> | |||
<currentLayout intoParentArea="true">Area</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>All keeps</breaksKeeps> | |||
</object> | |||
<object implemented="false"> | |||
<name>inline-container</name> | |||
<baseClass>FObj (1)</baseClass> | |||
<specContent><![CDATA[(%block;)+]]></specContent> | |||
<generatedAreas isReference="true"> | |||
<type><class>viewport/ref</class><stacking>inline</stacking></type> | |||
<multiplicity>1..*</multiplicity> | |||
<currentLayout/> | |||
</generatedAreas> | |||
<breaksKeeps>All keeps</breaksKeeps> | |||
<name>inline-container</name> | |||
<baseClass>FObj (1)</baseClass> | |||
<specContent><![CDATA[(%block;)+]]></specContent> | |||
<generatedAreas isReference="true"> | |||
<type><class>viewport/ref</class><stacking>inline</stacking></type> | |||
<multiplicity>1..*</multiplicity> | |||
<currentLayout/> | |||
</generatedAreas> | |||
<breaksKeeps>All keeps</breaksKeeps> | |||
</object> | |||
<object> | |||
<name>leader</name> | |||
<baseClass>FObjMixed</baseClass> | |||
<specContent><![CDATA[(#PCDATA|%inline;)*]]></specContent> | |||
<generatedAreas> | |||
<type><class>normal</class><stacking>inline</stacking></type> | |||
<multiplicity>1</multiplicity> | |||
<currentLayout intoParentArea="true">BlockArea</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps/> | |||
<name>leader</name> | |||
<baseClass>FObjMixed</baseClass> | |||
<specContent><![CDATA[(#PCDATA|%inline;)*]]></specContent> | |||
<generatedAreas> | |||
<type><class>normal</class><stacking>inline</stacking></type> | |||
<multiplicity>1</multiplicity> | |||
<currentLayout intoParentArea="true">BlockArea</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps/> | |||
</object> | |||
<object> | |||
<name>page-number</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent>EMPTY</specContent> | |||
<generatedAreas> | |||
<type><class>normal</class><stacking>inline</stacking></type> | |||
<multiplicity>1</multiplicity> | |||
<currentLayout intoParentArea="true">BlockArea (4)</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>kwn, kwp</breaksKeeps> | |||
<name>page-number</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent>EMPTY</specContent> | |||
<generatedAreas> | |||
<type><class>normal</class><stacking>inline</stacking></type> | |||
<multiplicity>1</multiplicity> | |||
<currentLayout intoParentArea="true">BlockArea (4)</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>kwn, kwp</breaksKeeps> | |||
</object> | |||
<object> | |||
<name>page-number-citation</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent>EMPTY</specContent> | |||
<generatedAreas> | |||
<type><class>normal</class><stacking>inline</stacking></type> | |||
<multiplicity>1</multiplicity> | |||
<currentLayout intoParentArea="true">BlockArea (4)</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>kwn, kwp</breaksKeeps> | |||
<name>page-number-citation</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent>EMPTY</specContent> | |||
<generatedAreas> | |||
<type><class>normal</class><stacking>inline</stacking></type> | |||
<multiplicity>1</multiplicity> | |||
<currentLayout intoParentArea="true">BlockArea (4)</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>kwn, kwp</breaksKeeps> | |||
</object> | |||
<object> | |||
<name>basic-link</name> | |||
<baseClass>FObjMixed</baseClass> | |||
<specContent><![CDATA[(#PCDATA|%inline;|%block;)*]]></specContent> | |||
<generatedAreas> | |||
<type><class>normal</class><stacking>inline</stacking></type> | |||
<multiplicity>1..*</multiplicity> | |||
<currentLayout intoParentArea="true">Area (4)</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>All keeps</breaksKeeps> | |||
<name>basic-link</name> | |||
<baseClass>FObjMixed</baseClass> | |||
<specContent><![CDATA[(#PCDATA|%inline;|%block;)*]]></specContent> | |||
<generatedAreas> | |||
<type><class>normal</class><stacking>inline</stacking></type> | |||
<multiplicity>1..*</multiplicity> | |||
<currentLayout intoParentArea="true">Area (4)</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>All keeps</breaksKeeps> | |||
</object> | |||
</category> | |||
<category class="other"> | |||
<object> | |||
<name>list-item-body</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent><![CDATA[(%block;)+]]></specContent> | |||
<generatedAreas> | |||
<type><class>None</class><stacking>None</stacking></type> | |||
<multiplicity/> | |||
<currentLayout intoParentArea="true">Area</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>kt</breaksKeeps> | |||
<name>list-item-body</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent><![CDATA[(%block;)+]]></specContent> | |||
<generatedAreas> | |||
<type><class>None</class><stacking>None</stacking></type> | |||
<multiplicity/> | |||
<currentLayout intoParentArea="true">Area</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>kt</breaksKeeps> | |||
</object> | |||
<object> | |||
<name>list-item</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent>(list-item-label,list-item-body)</specContent> | |||
<generatedAreas> | |||
<type><class>normal</class><stacking>block</stacking></type> | |||
<multiplicity>1..*</multiplicity> | |||
<currentLayout>BlockArea</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>All</breaksKeeps> | |||
<name>list-item</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent>(list-item-label,list-item-body)</specContent> | |||
<generatedAreas> | |||
<type><class>normal</class><stacking>block</stacking></type> | |||
<multiplicity>1..*</multiplicity> | |||
<currentLayout>BlockArea</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>All</breaksKeeps> | |||
</object> | |||
<object> | |||
<name>list-item-label</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent><![CDATA[(%block;)*]]></specContent> | |||
<generatedAreas> | |||
<type><class>None</class><stacking>None</stacking></type> | |||
<multiplicity/> | |||
<currentLayout intoParentArea="true">Area</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>kt</breaksKeeps> | |||
<name>list-item-label</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent><![CDATA[(%block;)*]]></specContent> | |||
<generatedAreas> | |||
<type><class>None</class><stacking>None</stacking></type> | |||
<multiplicity/> | |||
<currentLayout intoParentArea="true">Area</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps>kt</breaksKeeps> | |||
</object> | |||
<object> | |||
<name>table-body</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent>(table-row+|table-cell+)</specContent> | |||
<generatedAreas> | |||
<type><class>None</class><stacking>None</stacking></type> | |||
<multiplicity/> | |||
<currentLayout>AreaContainer (3)</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps/> | |||
<name>table-body</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent>(table-row+|table-cell+)</specContent> | |||
<generatedAreas> | |||
<type><class>None</class><stacking>None</stacking></type> | |||
<multiplicity/> | |||
<currentLayout>AreaContainer (3)</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps/> | |||
</object> | |||
<object implemented="false"> | |||
<name>table-caption</name> | |||
<baseClass>FObj (1)</baseClass> | |||
<specContent><![CDATA[(%block;)+]]></specContent> | |||
<generatedAreas> | |||
<type><class>normal</class><stacking>block</stacking></type> | |||
<multiplicity>1..*</multiplicity> | |||
<currentLayout/> | |||
</generatedAreas> | |||
<breaksKeeps>kt</breaksKeeps> | |||
<name>table-caption</name> | |||
<baseClass>FObj (1)</baseClass> | |||
<specContent><![CDATA[(%block;)+]]></specContent> | |||
<generatedAreas> | |||
<type><class>normal</class><stacking>block</stacking></type> | |||
<multiplicity>1..*</multiplicity> | |||
<currentLayout/> | |||
</generatedAreas> | |||
<breaksKeeps>kt</breaksKeeps> | |||
</object> | |||
<object> | |||
<name>table-cell</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent><![CDATA[(%block;)+]]></specContent> | |||
<generatedAreas isReference="true"> | |||
<type><class>normal</class><stacking>block</stacking></type> | |||
<multiplicity>1..*</multiplicity> | |||
<currentLayout>AreaContainer</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps/> | |||
<name>table-cell</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent><![CDATA[(%block;)+]]></specContent> | |||
<generatedAreas isReference="true"> | |||
<type><class>normal</class><stacking>block</stacking></type> | |||
<multiplicity>1..*</multiplicity> | |||
<currentLayout>AreaContainer</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps/> | |||
</object> | |||
<object> | |||
<name>table-column</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent>EMPTY</specContent> | |||
<generatedAreas/> | |||
<breaksKeeps/> | |||
<name>table-column</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent>EMPTY</specContent> | |||
<generatedAreas/> | |||
<breaksKeeps/> | |||
</object> | |||
<object> | |||
<name>table-footer</name> | |||
<baseClass>TableBody</baseClass> | |||
<specContent>(table-row+|table-cell+)</specContent> | |||
<generatedAreas> | |||
<type><class>None</class><stacking>None</stacking></type> | |||
<multiplicity/> | |||
<currentLayout>AreaContainer (3)</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps/> | |||
<name>table-footer</name> | |||
<baseClass>TableBody</baseClass> | |||
<specContent>(table-row+|table-cell+)</specContent> | |||
<generatedAreas> | |||
<type><class>None</class><stacking>None</stacking></type> | |||
<multiplicity/> | |||
<currentLayout>AreaContainer (3)</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps/> | |||
</object> | |||
<object> | |||
<name>table-header</name> | |||
<baseClass>TableBody</baseClass> | |||
<specContent>(table-row+|table-cell+)</specContent> | |||
<generatedAreas> | |||
<type><class>None</class><stacking>None</stacking></type> | |||
<multiplicity/> | |||
<currentLayout>AreaContainer (3)</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps/> | |||
<name>table-header</name> | |||
<baseClass>TableBody</baseClass> | |||
<specContent>(table-row+|table-cell+)</specContent> | |||
<generatedAreas> | |||
<type><class>None</class><stacking>None</stacking></type> | |||
<multiplicity/> | |||
<currentLayout>AreaContainer (3)</currentLayout> | |||
</generatedAreas> | |||
<breaksKeeps/> | |||
</object> | |||
<object> | |||
<name>table-row</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent>(table-cell+)</specContent> | |||
<generatedAreas/> | |||
<breaksKeeps>All</breaksKeeps> | |||
<name>table-row</name> | |||
<baseClass>FObj</baseClass> | |||
<specContent>(table-cell+)</specContent> | |||
<generatedAreas/> | |||
<breaksKeeps>All</breaksKeeps> | |||
</object> | |||
</category> | |||
<notes> |
@@ -1,14 +1,14 @@ | |||
<?xml version="1.0"?> | |||
<?xml version="1.0"?> | |||
<xsl:stylesheet | |||
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0" | |||
xmlns:fo="http://www.w3.org/1999/XSL/Format"> | |||
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0" | |||
xmlns:fo="http://www.w3.org/1999/XSL/Format"> | |||
<xsl:output method="html"/> | |||
<xsl:strip-space elements="*"/> | |||
<xsl:template match="/"> | |||
<xsl:apply-templates/> | |||
<xsl:apply-templates/> | |||
</xsl:template> | |||
<xsl:template match="formattingObjects"> | |||
@@ -31,69 +31,69 @@ | |||
</xsl:template> | |||
<xsl:template match="usage"> | |||
<xsl:apply-templates select="para"/> | |||
<xsl:apply-templates select="para"/> | |||
</xsl:template> | |||
<xsl:template match="para"> | |||
<p><xsl:apply-templates/></p> | |||
<p><xsl:apply-templates/></p> | |||
</xsl:template> | |||
<xsl:template match="em"> | |||
<em><xsl:apply-templates/></em> | |||
<em><xsl:apply-templates/></em> | |||
</xsl:template> | |||
<xsl:template match="term"> | |||
<b><xsl:apply-templates/></b> | |||
<b><xsl:apply-templates/></b> | |||
</xsl:template> | |||
<xsl:template match="category"> | |||
<table width="100%" cellpadding="5" cellspacing="1" border="1"> | |||
<tr> | |||
<th>Name</th><th>Base Class</th><th>Spec Content</th> | |||
<th>Generated Areas</th><th>Breaks and Keeps</th> | |||
</tr> | |||
<xsl:apply-templates select="object"/> | |||
</table> | |||
<table width="100%" cellpadding="5" cellspacing="1" border="1"> | |||
<tr> | |||
<th>Name</th><th>Base Class</th><th>Spec Content</th> | |||
<th>Generated Areas</th><th>Breaks and Keeps</th> | |||
</tr> | |||
<xsl:apply-templates select="object"/> | |||
</table> | |||
</xsl:template> | |||
<xsl:template match="object"> | |||
<tr> | |||
<td> | |||
<xsl:value-of select="name"/> | |||
<xsl:if test="self::node()[@implemented='false']"> *</xsl:if> | |||
</td> | |||
<td><xsl:value-of select="baseClass"/></td> | |||
<td><xsl:value-of select="specContent"/></td> | |||
<td><xsl:apply-templates select="generatedAreas"/></td> | |||
<td><xsl:value-of select="breaksKeeps"/> </td> | |||
</tr> | |||
<tr> | |||
<td> | |||
<xsl:value-of select="name"/> | |||
<xsl:if test="self::node()[@implemented='false']"> *</xsl:if> | |||
</td> | |||
<td><xsl:value-of select="baseClass"/></td> | |||
<td><xsl:value-of select="specContent"/></td> | |||
<td><xsl:apply-templates select="generatedAreas"/></td> | |||
<td><xsl:value-of select="breaksKeeps"/> </td> | |||
</tr> | |||
</xsl:template> | |||
<xsl:template match="generatedAreas"> | |||
<xsl:choose> | |||
<xsl:when test="currentLayout"> | |||
<ul> | |||
<li>Class: <xsl:value-of select="type/class"/>  | |||
Stacking: <xsl:value-of select="type/stacking"/></li> | |||
<li>Multiplicity: <xsl:value-of select="multiplicity"/></li> | |||
<li>Layout into: <xsl:value-of select="currentLayout"/> | |||
<xsl:if test="currentLayout[@intoParentArea='true']"> (parent)</xsl:if></li> | |||
<xsl:if test="self::node()[@isReference='true']"> | |||
<li>Reference Area(s)</li> | |||
</xsl:if> | |||
</ul> | |||
</xsl:when> | |||
<xsl:otherwise> </xsl:otherwise> | |||
<xsl:when test="currentLayout"> | |||
<ul> | |||
<li>Class: <xsl:value-of select="type/class"/>  | |||
Stacking: <xsl:value-of select="type/stacking"/></li> | |||
<li>Multiplicity: <xsl:value-of select="multiplicity"/></li> | |||
<li>Layout into: <xsl:value-of select="currentLayout"/> | |||
<xsl:if test="currentLayout[@intoParentArea='true']"> (parent)</xsl:if></li> | |||
<xsl:if test="self::node()[@isReference='true']"> | |||
<li>Reference Area(s)</li> | |||
</xsl:if> | |||
</ul> | |||
</xsl:when> | |||
<xsl:otherwise> </xsl:otherwise> | |||
</xsl:choose> | |||
</xsl:template> | |||
<xsl:template match="notes"> | |||
<p><b>Notes:</b></p> | |||
<ol> | |||
<xsl:for-each select="note"> | |||
<li><xsl:value-of select="."/></li> | |||
</xsl:for-each> | |||
</ol> | |||
<ol> | |||
<xsl:for-each select="note"> | |||
<li><xsl:value-of select="."/></li> | |||
</xsl:for-each> | |||
</ol> | |||
</xsl:template> | |||
</xsl:stylesheet> |
@@ -1,50 +1,50 @@ | |||
<?xml version="1.0" standalone="no"?> | |||
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20001102//EN" | |||
"http://www.w3.org/TR/2000/CR-SVG-20001102/DTD/svg-20001102.dtd"> | |||
"http://www.w3.org/TR/2000/CR-SVG-20001102/DTD/svg-20001102.dtd"> | |||
<svg width="440" height="250"> | |||
<rect x="5" y="5" width="151" height="239" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(0,0,0); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="260" y="6" width="151" height="239" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(0,0,0); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<polygon | |||
points="219.67,112 247,127 219.67,142 219.67,132.882 163,132.882 163,120.824 219.67,120.824" style=" | |||
stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(0,0,0); | |||
fill-opacity:1;fill:rgb(0,0,0);opacity:1"/> | |||
<path d="M4.5 31 L155.5 31" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-linecap:round;stroke-width:1;stroke-opacity:1; | |||
stroke:rgb(0,0,0);fill-opacity:1;fill:rgb(0,0,0);opacity:1"/> | |||
<path d="M260.5 32 L411.5 32" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-linecap:round;stroke-width:1;stroke-opacity:1; | |||
stroke:rgb(0,0,0);fill-opacity:1;fill:rgb(0,0,0);opacity:1"/> | |||
<path d="M5.5 222 L156.5 222" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-linecap:round;stroke-width:1;stroke-opacity:1; | |||
stroke:rgb(0,0,0);fill-opacity:1;fill:rgb(0,0,0);opacity:1"/> | |||
<path d="M261.5 220 L412.5 220" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-linecap:round;stroke-width:1;stroke-opacity:1; | |||
stroke:rgb(0,0,0);fill-opacity:1;fill:rgb(0,0,0);opacity:1"/> | |||
<path d="M23.5 32 L23.5 222" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-linecap:round;stroke-width:1;stroke-opacity:1; | |||
stroke:rgb(0,0,0);fill-opacity:1;fill:rgb(0,0,0);opacity:1"/> | |||
<path d="M133.5 32 L133.5 222" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-linecap:round;stroke-width:1;stroke-opacity:1; | |||
stroke:rgb(0,0,0);fill-opacity:1;fill:rgb(0,0,0);opacity:1"/> | |||
<path d="M282.5 31 L282.5 221" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-linecap:round;stroke-width:1;stroke-opacity:1; | |||
stroke:rgb(0,0,0);fill-opacity:1;fill:rgb(0,0,0);opacity:1"/> | |||
<path d="M389.5 31 L389.5 221" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-linecap:round;stroke-width:1;stroke-opacity:1; | |||
stroke:rgb(0,0,0);fill-opacity:1;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="283" y="33" width="106" height="32" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(58,53,255); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="283" y="71" width="106" height="27" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(58,53,255); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="283" y="107" width="106" height="28" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(58,53,255); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="283" y="143" width="106" height="32" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(58,53,255); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="282" y="187" width="108" height="13" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(58,53,255); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="282" y="208" width="108" height="27" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(58,53,255); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<path d="M282.5 50 L389.5 50" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-linecap:round;stroke-width:1;stroke-opacity:1; | |||
stroke:rgb(36,239,21);fill-opacity:1;fill:rgb(0,0,0);opacity:1"/> | |||
<path d="M283.5 195 L390.5 195" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-linecap:round;stroke-width:1;stroke-opacity:1; | |||
stroke:rgb(36,239,21);fill-opacity:1;fill:rgb(0,0,0);opacity:1"/> | |||
<text x="361" y="46" style="font-family:Arial;font-size:12;stroke-width:1;stroke-opacity:1;stroke:rgb(0,0,0); | |||
fill-opacity:1;fill:rgb(0,0,0);opacity:1">Before Float</text> | |||
<text x="379.157" y="211" style="font-family:Arial;font-size:12;stroke-width:1;stroke-opacity:1;stroke:rgb(0,0,0); | |||
fill-opacity:1;fill:rgb(0,0,0);opacity:1">Footnote</text> | |||
<rect x="5" y="5" width="151" height="239" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(0,0,0); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="260" y="6" width="151" height="239" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(0,0,0); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<polygon | |||
points="219.67,112 247,127 219.67,142 219.67,132.882 163,132.882 163,120.824 219.67,120.824" style=" | |||
stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(0,0,0); | |||
fill-opacity:1;fill:rgb(0,0,0);opacity:1"/> | |||
<path d="M4.5 31 L155.5 31" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-linecap:round;stroke-width:1;stroke-opacity:1; | |||
stroke:rgb(0,0,0);fill-opacity:1;fill:rgb(0,0,0);opacity:1"/> | |||
<path d="M260.5 32 L411.5 32" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-linecap:round;stroke-width:1;stroke-opacity:1; | |||
stroke:rgb(0,0,0);fill-opacity:1;fill:rgb(0,0,0);opacity:1"/> | |||
<path d="M5.5 222 L156.5 222" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-linecap:round;stroke-width:1;stroke-opacity:1; | |||
stroke:rgb(0,0,0);fill-opacity:1;fill:rgb(0,0,0);opacity:1"/> | |||
<path d="M261.5 220 L412.5 220" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-linecap:round;stroke-width:1;stroke-opacity:1; | |||
stroke:rgb(0,0,0);fill-opacity:1;fill:rgb(0,0,0);opacity:1"/> | |||
<path d="M23.5 32 L23.5 222" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-linecap:round;stroke-width:1;stroke-opacity:1; | |||
stroke:rgb(0,0,0);fill-opacity:1;fill:rgb(0,0,0);opacity:1"/> | |||
<path d="M133.5 32 L133.5 222" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-linecap:round;stroke-width:1;stroke-opacity:1; | |||
stroke:rgb(0,0,0);fill-opacity:1;fill:rgb(0,0,0);opacity:1"/> | |||
<path d="M282.5 31 L282.5 221" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-linecap:round;stroke-width:1;stroke-opacity:1; | |||
stroke:rgb(0,0,0);fill-opacity:1;fill:rgb(0,0,0);opacity:1"/> | |||
<path d="M389.5 31 L389.5 221" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-linecap:round;stroke-width:1;stroke-opacity:1; | |||
stroke:rgb(0,0,0);fill-opacity:1;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="283" y="33" width="106" height="32" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(58,53,255); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="283" y="71" width="106" height="27" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(58,53,255); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="283" y="107" width="106" height="28" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(58,53,255); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="283" y="143" width="106" height="32" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(58,53,255); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="282" y="187" width="108" height="13" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(58,53,255); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<rect x="282" y="208" width="108" height="27" rx="0" ry="0" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-width:1;stroke-opacity:1;stroke:rgb(58,53,255); | |||
fill-opacity:0;fill:rgb(0,0,0);opacity:1"/> | |||
<path d="M282.5 50 L389.5 50" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-linecap:round;stroke-width:1;stroke-opacity:1; | |||
stroke:rgb(36,239,21);fill-opacity:1;fill:rgb(0,0,0);opacity:1"/> | |||
<path d="M283.5 195 L390.5 195" style="stroke-miterlimit:4;stroke-linejoin:miter;stroke-linecap:round;stroke-width:1;stroke-opacity:1; | |||
stroke:rgb(36,239,21);fill-opacity:1;fill:rgb(0,0,0);opacity:1"/> | |||
<text x="361" y="46" style="font-family:Arial;font-size:12;stroke-width:1;stroke-opacity:1;stroke:rgb(0,0,0); | |||
fill-opacity:1;fill:rgb(0,0,0);opacity:1">Before Float</text> | |||
<text x="379.157" y="211" style="font-family:Arial;font-size:12;stroke-width:1;stroke-opacity:1;stroke:rgb(0,0,0); | |||
fill-opacity:1;fill:rgb(0,0,0);opacity:1">Footnote</text> | |||
</svg> | |||