mirrors
/
fop
mirror of https://github.com/apache/fop.git
Watch 1
Star 0
Fork 0
Code Issues 0 Releases 48 Wiki Activity
Browse Source

white-space and line-ending fixes 


git-svn-id: https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk@195684 13f79535-47bb-0310-9956-ffa450edef68
tags/Alt-Design-integration-base
William Victor Mote 21 years ago
parent
8d3f23d192
commit
64b3c5ede2
24 changed files with 2834 additions and 2834 deletions
Split View Show Diff Stats
  1. 1
    1
      docs/design/alt.design/AbsolutePosition.png.xml
  2. 1
    1
      docs/design/alt.design/BorderCommonStyle.png.xml
  3. 1
    1
      docs/design/alt.design/PropNames.png.xml
  4. 1
    1
      docs/design/alt.design/Properties.png.xml
  5. 1
    1
      docs/design/alt.design/PropertyConsts.png.xml
  6. 1
    1
      docs/design/alt.design/VerticalAlign.png.xml
  7. 125
    125
      docs/design/alt.design/alt.properties.xml
  8. 172
    172
      docs/design/alt.design/classes-overview.xml
  9. 198
    198
      docs/design/alt.design/compound-properties.xml
  10. 90
    90
      docs/design/alt.design/coroutines.xml
  11. 108
    108
      docs/design/alt.design/footnotes.xml
  12. 181
    181
      docs/design/alt.design/galleys.xml
  13. 52
    52
      docs/design/alt.design/intro.xml
  14. 84
    84
      docs/design/alt.design/keeps.xml
  15. 111
    111
      docs/design/alt.design/properties-classes.xml
  16. 278
    278
      docs/design/alt.design/propertyExpressions.xml
  17. 150
    150
      docs/design/alt.design/spaces.xml
  18. 62
    62
      docs/design/alt.design/traits.xml
  19. 669
    669
      docs/design/alt.design/user-agent-refs.xml
  20. 193
    193
      docs/design/alt.design/xml-parsing.xml
  21. 43
    43
      docs/design/float.svg
  22. 223
    223
      docs/design/fo_impl/fo_classes.xml
  23. 44
    44
      docs/design/fo_impl/fo_classes.xsl
  24. 45
    45
      docs/design/page.svg

+ 1
- 1
docs/design/alt.design/AbsolutePosition.png.xml View File

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

+ 1
- 1
docs/design/alt.design/BorderCommonStyle.png.xml View File

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

+ 1
- 1
docs/design/alt.design/PropNames.png.xml View File

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

+ 1
- 1
docs/design/alt.design/Properties.png.xml View File

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

+ 1
- 1
docs/design/alt.design/PropertyConsts.png.xml View File

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

+ 1
- 1
docs/design/alt.design/VerticalAlign.png.xml View File

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

+ 125
- 125
docs/design/alt.design/alt.properties.xml View File

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

+ 172
- 172
docs/design/alt.design/classes-overview.xml View File

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

+ 198
- 198
docs/design/alt.design/compound-properties.xml View File

@@ -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>&lt;length-range&gt;</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>&lt;length-conditional&gt;</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>&lt;length-bp-ip-direction&gt;</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>&lt;space&gt;</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>&lt;keep&gt;</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>&lt;length-range&gt;</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>&lt;length-conditional&gt;</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>&lt;length-bp-ip-direction&gt;</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>&lt;space&gt;</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>&lt;keep&gt;</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>

+ 90
- 90
docs/design/alt.design/coroutines.xml View File

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

+ 108
- 108
docs/design/alt.design/footnotes.xml View File

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

+ 181
- 181
docs/design/alt.design/galleys.xml View File

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

+ 52
- 52
docs/design/alt.design/intro.xml View File

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


+ 84
- 84
docs/design/alt.design/keeps.xml View File

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

+ 111
- 111
docs/design/alt.design/properties-classes.xml View File

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

+ 278
- 278
docs/design/alt.design/propertyExpressions.xml View File

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

+ 150
- 150
docs/design/alt.design/spaces.xml View File

@@ -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
&lt;space&gt;s. It may be helpful to think of <em>stacking
constraints</em> as <em>&lt;space&gt;s interaction</em> or
<em>&lt;space&gt;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
&lt;space&gt;s. It may be helpful to think of <em>stacking
constraints</em> as <em>&lt;space&gt;s interaction</em> or
<em>&lt;space&gt;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 &lt;space&gt;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 &lt;space&gt;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 &lt;space&gt;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 &lt;space&gt;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>

+ 62
- 62
docs/design/alt.design/traits.xml View File

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

+ 669
- 669
docs/design/alt.design/user-agent-refs.xml
File diff suppressed because it is too large
View File


+ 193
- 193
docs/design/alt.design/xml-parsing.xml View File

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

+ 43
- 43
docs/design/float.svg View File

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


+ 223
- 223
docs/design/fo_impl/fo_classes.xml View File

@@ -72,289 +72,289 @@ parent.
The Name, Spec Content, and Breaks &amp; 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>

+ 44
- 44
docs/design/fo_impl/fo_classes.xsl View File

@@ -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']">&#0160;*</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"/>&#0160;</td>
</tr>
<tr>
<td>
<xsl:value-of select="name"/>
<xsl:if test="self::node()[@implemented='false']">&#0160;*</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"/>&#0160;</td>
</tr>
</xsl:template>

<xsl:template match="generatedAreas">
<xsl:choose>
<xsl:when test="currentLayout">
<ul>
<li>Class: <xsl:value-of select="type/class"/>&#0160;
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']">&#0160;(parent)</xsl:if></li>
<xsl:if test="self::node()[@isReference='true']">
<li>Reference Area(s)</li>
</xsl:if>
</ul>
</xsl:when>
<xsl:otherwise>&#0160;</xsl:otherwise>
<xsl:when test="currentLayout">
<ul>
<li>Class: <xsl:value-of select="type/class"/>&#0160;
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']">&#0160;(parent)</xsl:if></li>
<xsl:if test="self::node()[@isReference='true']">
<li>Reference Area(s)</li>
</xsl:if>
</ul>
</xsl:when>
<xsl:otherwise>&#0160;</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>

+ 45
- 45
docs/design/page.svg View File

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


Write Preview
Loading…
Cancel
Save