diff options
| author | William Victor Mote <vmote@apache.org> | 2002-11-30 07:24:10 +0000 |
|---|---|---|
| committer | William Victor Mote <vmote@apache.org> | 2002-11-30 07:24:10 +0000 |
| commit | 64b3c5ede295343029ded69bb7f035ddd47409f3 (patch) | |
| tree | 8e9c4dbe474b2f537f5cb02b8ac7636bef9b8a87 /docs | |
| parent | 8d3f23d1924ceb5822daa3c280864fd58815f8c5 (diff) | |
| download | xmlgraphics-fop-64b3c5ede295343029ded69bb7f035ddd47409f3.tar.gz xmlgraphics-fop-64b3c5ede295343029ded69bb7f035ddd47409f3.zip | |
white-space and line-ending fixes
git-svn-id: https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk@195684 13f79535-47bb-0310-9956-ffa450edef68
Diffstat (limited to 'docs')
24 files changed, 2834 insertions, 2834 deletions
diff --git a/docs/design/alt.design/AbsolutePosition.png.xml b/docs/design/alt.design/AbsolutePosition.png.xml index 7b2cde0bc..57af6a926 100644 --- a/docs/design/alt.design/AbsolutePosition.png.xml +++ b/docs/design/alt.design/AbsolutePosition.png.xml @@ -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> diff --git a/docs/design/alt.design/BorderCommonStyle.png.xml b/docs/design/alt.design/BorderCommonStyle.png.xml index f57865bc2..a81ba9cae 100644 --- a/docs/design/alt.design/BorderCommonStyle.png.xml +++ b/docs/design/alt.design/BorderCommonStyle.png.xml @@ -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> diff --git a/docs/design/alt.design/PropNames.png.xml b/docs/design/alt.design/PropNames.png.xml index 829509d8b..c851da75e 100644 --- a/docs/design/alt.design/PropNames.png.xml +++ b/docs/design/alt.design/PropNames.png.xml @@ -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> diff --git a/docs/design/alt.design/Properties.png.xml b/docs/design/alt.design/Properties.png.xml index f2a53578c..749ac651e 100644 --- a/docs/design/alt.design/Properties.png.xml +++ b/docs/design/alt.design/Properties.png.xml @@ -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> diff --git a/docs/design/alt.design/PropertyConsts.png.xml b/docs/design/alt.design/PropertyConsts.png.xml index 73d509cae..69f71afcc 100644 --- a/docs/design/alt.design/PropertyConsts.png.xml +++ b/docs/design/alt.design/PropertyConsts.png.xml @@ -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> diff --git a/docs/design/alt.design/VerticalAlign.png.xml b/docs/design/alt.design/VerticalAlign.png.xml index 6ff21bb00..61c60b354 100644 --- a/docs/design/alt.design/VerticalAlign.png.xml +++ b/docs/design/alt.design/VerticalAlign.png.xml @@ -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> diff --git a/docs/design/alt.design/alt.properties.xml b/docs/design/alt.design/alt.properties.xml index 6a3f7be3b..51caba702 100644 --- a/docs/design/alt.design/alt.properties.xml +++ b/docs/design/alt.design/alt.properties.xml @@ -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> diff --git a/docs/design/alt.design/classes-overview.xml b/docs/design/alt.design/classes-overview.xml index fab8e921d..d00762466 100644 --- a/docs/design/alt.design/classes-overview.xml +++ b/docs/design/alt.design/classes-overview.xml @@ -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> diff --git a/docs/design/alt.design/compound-properties.xml b/docs/design/alt.design/compound-properties.xml index 3b20add15..94d4b2580 100644 --- a/docs/design/alt.design/compound-properties.xml +++ b/docs/design/alt.design/compound-properties.xml @@ -14,204 +14,204 @@ <body> <s1 title="Compound properties in XSLFO"> <table> - <tr> - <th>Property type</th> - <th>Section</th> - <th>Inherited</th> - <th>'inherit'</th> - </tr> - <tr> - <th><length-range></th> - </tr> - <tr> - <th>minimum</th> - </tr> - <tr> - <th>optimum</th> - </tr> - <tr> - <th>maximum</th> - </tr> - <tr> - <td>block-progression-dimension</td> - <td>7.14.1</td> - <td>no</td> - <td>yes</td> - </tr> - <tr> - <td>inline-progression-dimension</td> - <td>7.14.5</td> - <td>no</td> - <td>yes</td> - </tr> - <tr> - <td>leader-length</td> - <td>7.21.4</td> - <td>yes</td> - <td>yes</td> - </tr> - <tr> - <th><length-conditional></th> - </tr> - <tr> - <th>length</th> - </tr> - <tr> - <th>conditionality</th> - </tr> - <tr> - <td>border-after-width</td> - <td>7.7.12</td> - <td>no</td> - <td>yes</td> - </tr> - <tr> - <td>border-before-width</td> - <td>7.7.9</td> - <td>no</td> - <td>yes</td> - </tr> - <tr> - <td>border-end-width</td> - <td>7.7.18</td> - <td>no</td> - <td>yes</td> - </tr> - <tr> - <td>border-start-width</td> - <td>7.7.15</td> - <td>no</td> - <td>yes</td> - </tr> - <tr> - <td>padding-after</td> - <td>7.7.32</td> - <td>no</td> - <td>yes</td> - </tr> - <tr> - <td>padding-before</td> - <td>7.7.31</td> - <td>no</td> - <td>yes</td> - </tr> - <tr> - <td>padding-end</td> - <td>7.7.34</td> - <td>no</td> - <td>yes</td> - </tr> - <tr> - <td>padding-start</td> - <td>7.7.33</td> - <td>no</td> - <td>yes</td> - </tr> - <tr> - <th><length-bp-ip-direction></th> - </tr> - <tr> - <th>block-progression-direction</th> - </tr> - <tr> - <th>inline-progression-direction</th> - </tr> - <tr> - <td>border-separation</td> - <td>7.26.5</td> - <td>yes</td> - <td>yes</td> - </tr> - <tr> - <th><space></th> - </tr> - <tr> - <th>minimum</th> - </tr> - <tr> - <th>optimum</th> - </tr> - <tr> - <th>maximum</th> - </tr> - <tr> - <th>precedence</th> - </tr> - <tr> - <th>conditionality</th> - </tr> - <tr> - <td>letter-spacing</td> - <td>7.16.2</td> - <td>yes</td> - <td>yes</td> - </tr> - <tr> - <td>line-height</td> - <td>7.15.4</td> - <td>yes</td> - <td>yes</td> - </tr> - <tr> - <td>space-after</td> - <td>7.10.6</td> - <td>no</td> - <td>yes</td> - </tr> - <tr> - <td>space-before</td> - <td>7.10.5</td> - <td>no</td> - <td>yes</td> - </tr> - <tr> - <td>space-end</td> - <td>7.11.1</td> - <td>no</td> - <td>yes</td> - </tr> - <tr> - <td>space-start</td> - <td>7.11.2</td> - <td>no</td> - <td>yes</td> - </tr> - <tr> - <td>word-spacing</td> - <td>7.16.8</td> - <td>yes</td> - <td>yes</td> - </tr> - <tr> - <th><keep></th> - </tr> - <tr> - <th>within-line</th> - </tr> - <tr> - <th>within-column</th> - </tr> - <tr> - <th>within-page</th> - </tr> - <tr> - <td>keep-together</td> - <td>7.19.3</td> - <td>yes</td> - <td>yes</td> - </tr> - <tr> - <td>keep-with-next</td> - <td>7.19.4</td> - <td>no</td> - <td>yes</td> - </tr> - <tr> - <td>keep-with-previous</td> - <td>7.19.5</td> - <td>no</td> - <td>yes</td> - </tr> + <tr> + <th>Property type</th> + <th>Section</th> + <th>Inherited</th> + <th>'inherit'</th> + </tr> + <tr> + <th><length-range></th> + </tr> + <tr> + <th>minimum</th> + </tr> + <tr> + <th>optimum</th> + </tr> + <tr> + <th>maximum</th> + </tr> + <tr> + <td>block-progression-dimension</td> + <td>7.14.1</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>inline-progression-dimension</td> + <td>7.14.5</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>leader-length</td> + <td>7.21.4</td> + <td>yes</td> + <td>yes</td> + </tr> + <tr> + <th><length-conditional></th> + </tr> + <tr> + <th>length</th> + </tr> + <tr> + <th>conditionality</th> + </tr> + <tr> + <td>border-after-width</td> + <td>7.7.12</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>border-before-width</td> + <td>7.7.9</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>border-end-width</td> + <td>7.7.18</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>border-start-width</td> + <td>7.7.15</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>padding-after</td> + <td>7.7.32</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>padding-before</td> + <td>7.7.31</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>padding-end</td> + <td>7.7.34</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>padding-start</td> + <td>7.7.33</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <th><length-bp-ip-direction></th> + </tr> + <tr> + <th>block-progression-direction</th> + </tr> + <tr> + <th>inline-progression-direction</th> + </tr> + <tr> + <td>border-separation</td> + <td>7.26.5</td> + <td>yes</td> + <td>yes</td> + </tr> + <tr> + <th><space></th> + </tr> + <tr> + <th>minimum</th> + </tr> + <tr> + <th>optimum</th> + </tr> + <tr> + <th>maximum</th> + </tr> + <tr> + <th>precedence</th> + </tr> + <tr> + <th>conditionality</th> + </tr> + <tr> + <td>letter-spacing</td> + <td>7.16.2</td> + <td>yes</td> + <td>yes</td> + </tr> + <tr> + <td>line-height</td> + <td>7.15.4</td> + <td>yes</td> + <td>yes</td> + </tr> + <tr> + <td>space-after</td> + <td>7.10.6</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>space-before</td> + <td>7.10.5</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>space-end</td> + <td>7.11.1</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>space-start</td> + <td>7.11.2</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>word-spacing</td> + <td>7.16.8</td> + <td>yes</td> + <td>yes</td> + </tr> + <tr> + <th><keep></th> + </tr> + <tr> + <th>within-line</th> + </tr> + <tr> + <th>within-column</th> + </tr> + <tr> + <th>within-page</th> + </tr> + <tr> + <td>keep-together</td> + <td>7.19.3</td> + <td>yes</td> + <td>yes</td> + </tr> + <tr> + <td>keep-with-next</td> + <td>7.19.4</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>keep-with-previous</td> + <td>7.19.5</td> + <td>no</td> + <td>yes</td> + </tr> </table> </s1> </body> diff --git a/docs/design/alt.design/coroutines.xml b/docs/design/alt.design/coroutines.xml index 8d39d1730..b76eab1b8 100644 --- a/docs/design/alt.design/coroutines.xml +++ b/docs/design/alt.design/coroutines.xml @@ -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> diff --git a/docs/design/alt.design/footnotes.xml b/docs/design/alt.design/footnotes.xml index 0e2ce4bba..a97f1aed6 100644 --- a/docs/design/alt.design/footnotes.xml +++ b/docs/design/alt.design/footnotes.xml @@ -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> diff --git a/docs/design/alt.design/galleys.xml b/docs/design/alt.design/galleys.xml index e26f2755d..0175a583e 100644 --- a/docs/design/alt.design/galleys.xml +++ b/docs/design/alt.design/galleys.xml @@ -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> diff --git a/docs/design/alt.design/intro.xml b/docs/design/alt.design/intro.xml index 39fdc1e64..0af32f20e 100644 --- a/docs/design/alt.design/intro.xml +++ b/docs/design/alt.design/intro.xml @@ -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> diff --git a/docs/design/alt.design/keeps.xml b/docs/design/alt.design/keeps.xml index 9c428c46c..3ff533924 100644 --- a/docs/design/alt.design/keeps.xml +++ b/docs/design/alt.design/keeps.xml @@ -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> diff --git a/docs/design/alt.design/properties-classes.xml b/docs/design/alt.design/properties-classes.xml index 216f2b9e0..6f652fd4d 100644 --- a/docs/design/alt.design/properties-classes.xml +++ b/docs/design/alt.design/properties-classes.xml @@ -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> diff --git a/docs/design/alt.design/propertyExpressions.xml b/docs/design/alt.design/propertyExpressions.xml index 0900a323a..7ebbcd4fe 100644 --- a/docs/design/alt.design/propertyExpressions.xml +++ b/docs/design/alt.design/propertyExpressions.xml @@ -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> diff --git a/docs/design/alt.design/spaces.xml b/docs/design/alt.design/spaces.xml index c9d56a057..80bb8c46d 100644 --- a/docs/design/alt.design/spaces.xml +++ b/docs/design/alt.design/spaces.xml @@ -15,162 +15,162 @@ <!-- one of (anchor s1) --> <s1 title="Keeps and space-specifiers in layout galleys"> <p> - The <link href= "galleys.html" >layout galleys</link> and the - <link href= "galleys.html#layout-tree" >layout tree</link> - which is the context of this discussion have been discussed - elsewhere. A <link href="keeps.html">previous document</link> - discussed data structures which might facilitate the lining of - blocks necessary to implement keeps. Here we discuss the - similarities between the keep data structures and those - required to implement space-specifier resolution. + The <link href= "galleys.html" >layout galleys</link> and the + <link href= "galleys.html#layout-tree" >layout tree</link> + which is the context of this discussion have been discussed + elsewhere. A <link href="keeps.html">previous document</link> + discussed data structures which might facilitate the lining of + blocks necessary to implement keeps. Here we discuss the + similarities between the keep data structures and those + required to implement space-specifier resolution. </p> <s2 title="Space-specifiers"> - <note> - <strong>4.3 Spaces and Conditionality</strong> - ... Space-specifiers occurring in sequence may interact with - each other. The constraint imposed by a sequence of - space-specifiers is computed by calculating for each - space-specifier its associated resolved space-specifier in - accordance with their conditionality and precedence. - </note> - <note> - 4.2.5 Stacking Constraints ... The intention of the - definitions is to identify areas at any level of the tree - which have only space between them. - </note> - <p> - The quotations above are pivotal to understanding the - complex discussion of spaces with which they are associated, - all of which exists to enable the resolution of adjacent - <space>s. It may be helpful to think of <em>stacking - constraints</em> as <em><space>s interaction</em> or - <em><space>s stacking interaction</em>. - </p> + <note> + <strong>4.3 Spaces and Conditionality</strong> + ... Space-specifiers occurring in sequence may interact with + each other. The constraint imposed by a sequence of + space-specifiers is computed by calculating for each + space-specifier its associated resolved space-specifier in + accordance with their conditionality and precedence. + </note> + <note> + 4.2.5 Stacking Constraints ... The intention of the + definitions is to identify areas at any level of the tree + which have only space between them. + </note> + <p> + The quotations above are pivotal to understanding the + complex discussion of spaces with which they are associated, + all of which exists to enable the resolution of adjacent + <space>s. It may be helpful to think of <em>stacking + constraints</em> as <em><space>s interaction</em> or + <em><space>s stacking interaction</em>. + </p> </s2> <s2 title="Block stacking constraints"> - <p> - In the discussion of block stacking constraints in Section - 4.2.5, the notion of <em>fence</em> is introduced. For - block stacking constraints, a fence is defined as either a - reference-area boundary or a non-zero padding or border - specification. Fences, however, do not come into play - when determining the constraint between siblings. (See - <link href="#Figure1">Figure 1</link>.) - </p> - <p><strong>Figure 1</strong></p><anchor id="Figure1"/> - <figure src="block-stacking-constraints.png" - alt="block-stacking-constraints.png"/> - <note> - Figure 1 assumes a block-progression-direction of top to - bottom. - </note> - <p> - In <link href="#Figure1">Diagram a)</link>, block A has - non-zero padding and borders, in addition to non-zero - spaces. Note, however, that the space-after of A is - adjacent to the space-before of block P, so borders and - padding on these siblings have no impact on the interaction - of their <space>s. The stacking constraint A,P is - indicated by the red rectangle enclosing the space-after of - A and the space-before of P. - </p> - <p> - In <link href="#Figure1">Diagram b)</link>, block B is the - first block child of P. The stacking constraint A,P is as - before; the stacking constraint P,B is the space-before of - B, as indicated by the enclosing magenta rectangle. In this - case, however, the non-zero border of P prevents the - interaction of the A,P and P,B stacking constraints. There - is a <em>fence-before</em> P. The fence is notional; it has - no precise location, as the diagram may lead one to believe. - </p> - <p> - In <link href="#Figure1">Diagram c)</link>, because of the - zero-width borders and padding on block P, the fence-before - P is not present, and the adjacent <space>s of blocks - A, P and B are free to interact. In this case, the stacking - constraints A,P and P,B are as before, but now there is an - additional stacking constraint A,B, represented by the light - brown rectangle enclosing the other two stacking - constraints. - </p> - <p> - The other form of fence occurs when the parent block is a - reference area. Diagram b) of <link href="#Figure2">Figure - 2</link> illustrates this situation. Block C is a - reference-area, involving a 180 degree change of - block-progression-direction (BPD). In the diagram, the - inner edge of block C represents the content rectangle, with - its changed BPD. The thicker outer edge represents the - outer boundary of the padding, border and spaces of C. - </p> - <p> - While not every reference-area will change the - inline-progression-direction (IPD) and BPD of an area, no - attempt is made to discriminate these cases. A - reference-area always a fence. The fence comes into play in - analogous circumstances to non-zero borders or padding. - Space resolution between a reference area and its siblings - is not affected. - </p> - <p> - In the case of <link href="#Figure2">Diagram b)</link>, - these are block stacking constraints B,C and C,A. Within - the reference-area, bock stacing constraints C,D and E,C are - unaffected. However, the fence prevents block stacking - constraints such as B,E or D,A. When there is a change of - BPD, as <link href="#Figure2">Diagram b)</link> makes - visually obvious, it is difficult to imagine which blocks - would have such a constraint, and what the ordering of the - constraint would be. - </p> - <p><strong>Figure 2</strong></p> - <anchor id="Figure2"/> - <figure src="block-stacking-keeps.png" - alt="block-stacking-keeps.png"/> + <p> + In the discussion of block stacking constraints in Section + 4.2.5, the notion of <em>fence</em> is introduced. For + block stacking constraints, a fence is defined as either a + reference-area boundary or a non-zero padding or border + specification. Fences, however, do not come into play + when determining the constraint between siblings. (See + <link href="#Figure1">Figure 1</link>.) + </p> + <p><strong>Figure 1</strong></p><anchor id="Figure1"/> + <figure src="block-stacking-constraints.png" + alt="block-stacking-constraints.png"/> + <note> + Figure 1 assumes a block-progression-direction of top to + bottom. + </note> + <p> + In <link href="#Figure1">Diagram a)</link>, block A has + non-zero padding and borders, in addition to non-zero + spaces. Note, however, that the space-after of A is + adjacent to the space-before of block P, so borders and + padding on these siblings have no impact on the interaction + of their <space>s. The stacking constraint A,P is + indicated by the red rectangle enclosing the space-after of + A and the space-before of P. + </p> + <p> + In <link href="#Figure1">Diagram b)</link>, block B is the + first block child of P. The stacking constraint A,P is as + before; the stacking constraint P,B is the space-before of + B, as indicated by the enclosing magenta rectangle. In this + case, however, the non-zero border of P prevents the + interaction of the A,P and P,B stacking constraints. There + is a <em>fence-before</em> P. The fence is notional; it has + no precise location, as the diagram may lead one to believe. + </p> + <p> + In <link href="#Figure1">Diagram c)</link>, because of the + zero-width borders and padding on block P, the fence-before + P is not present, and the adjacent <space>s of blocks + A, P and B are free to interact. In this case, the stacking + constraints A,P and P,B are as before, but now there is an + additional stacking constraint A,B, represented by the light + brown rectangle enclosing the other two stacking + constraints. + </p> + <p> + The other form of fence occurs when the parent block is a + reference area. Diagram b) of <link href="#Figure2">Figure + 2</link> illustrates this situation. Block C is a + reference-area, involving a 180 degree change of + block-progression-direction (BPD). In the diagram, the + inner edge of block C represents the content rectangle, with + its changed BPD. The thicker outer edge represents the + outer boundary of the padding, border and spaces of C. + </p> + <p> + While not every reference-area will change the + inline-progression-direction (IPD) and BPD of an area, no + attempt is made to discriminate these cases. A + reference-area always a fence. The fence comes into play in + analogous circumstances to non-zero borders or padding. + Space resolution between a reference area and its siblings + is not affected. + </p> + <p> + In the case of <link href="#Figure2">Diagram b)</link>, + these are block stacking constraints B,C and C,A. Within + the reference-area, bock stacing constraints C,D and E,C are + unaffected. However, the fence prevents block stacking + constraints such as B,E or D,A. When there is a change of + BPD, as <link href="#Figure2">Diagram b)</link> makes + visually obvious, it is difficult to imagine which blocks + would have such a constraint, and what the ordering of the + constraint would be. + </p> + <p><strong>Figure 2</strong></p> + <anchor id="Figure2"/> + <figure src="block-stacking-keeps.png" + alt="block-stacking-keeps.png"/> </s2> <s2 title="Keep relationships between blocks"> - <p> - As complicated as space-specifiers become when - reference-areas are involved, the keep relationships as - described in the <link - href="keeps.html#Figure1">keeps</link> document, are - unchanged. This is also illustrated in <link - href="#Figure2">Figure 2</link>. Diagram b) shows the - relative placement of blocks in the rendered output when a - 180 degree change of BPD occurs, with blocks D and E - stacking in the reverse direction to blocks B and C. - Diagram c) shows what happens when the page is too short to - accommodate the last block. D is still laid out, but E is - deferred to the next page. - </p> - <p> - Note that this rendering reality is expressed directly in - the area (and layout) tree view. Consequently, any keep - relationships expressed as links threading through the - layout tree will not need to be modified to account for - reference-area boundaries, as is the case with similar - space-specifier edge links. E.g., a keep-with-next - condition on block B can be resolved along the path of these - links (B->C->D) into a direct relationship of B->D, - irrespective of the reference-area boundary. - </p> - <p> - While the same relationships obviously hold when a reference - area induces no change of BPD, the situation for BPD changes - perpendicular to the parent's BPD may not be so clear. In - general, it probably does not make much sense to impose keep - conditions across such a boundary, but there seems to be - nothing preventing such conditions. They can be dealt with - in the same way, i.e., the next leaf block linked in area - tree order must be the next laid out. If a keep condition - is in place, an attempt must be made to meet it. A number - of unusual considerations would apply, e.g. the minimum - inline-progression-dimension of the first leaf block within - the reference-area as compared to the minimum IPD of - subsequent blocks, but <em>prima facie</em>, the essential - logic of the keeps links remains. - </p> + <p> + As complicated as space-specifiers become when + reference-areas are involved, the keep relationships as + described in the <link + href="keeps.html#Figure1">keeps</link> document, are + unchanged. This is also illustrated in <link + href="#Figure2">Figure 2</link>. Diagram b) shows the + relative placement of blocks in the rendered output when a + 180 degree change of BPD occurs, with blocks D and E + stacking in the reverse direction to blocks B and C. + Diagram c) shows what happens when the page is too short to + accommodate the last block. D is still laid out, but E is + deferred to the next page. + </p> + <p> + Note that this rendering reality is expressed directly in + the area (and layout) tree view. Consequently, any keep + relationships expressed as links threading through the + layout tree will not need to be modified to account for + reference-area boundaries, as is the case with similar + space-specifier edge links. E.g., a keep-with-next + condition on block B can be resolved along the path of these + links (B->C->D) into a direct relationship of B->D, + irrespective of the reference-area boundary. + </p> + <p> + While the same relationships obviously hold when a reference + area induces no change of BPD, the situation for BPD changes + perpendicular to the parent's BPD may not be so clear. In + general, it probably does not make much sense to impose keep + conditions across such a boundary, but there seems to be + nothing preventing such conditions. They can be dealt with + in the same way, i.e., the next leaf block linked in area + tree order must be the next laid out. If a keep condition + is in place, an attempt must be made to meet it. A number + of unusual considerations would apply, e.g. the minimum + inline-progression-dimension of the first leaf block within + the reference-area as compared to the minimum IPD of + subsequent blocks, but <em>prima facie</em>, the essential + logic of the keeps links remains. + </p> </s2> </s1> </body> diff --git a/docs/design/alt.design/traits.xml b/docs/design/alt.design/traits.xml index c761af8d7..c983c371a 100644 --- a/docs/design/alt.design/traits.xml +++ b/docs/design/alt.design/traits.xml @@ -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> diff --git a/docs/design/alt.design/user-agent-refs.xml b/docs/design/alt.design/user-agent-refs.xml index 19a199c68..2cca58beb 100644 --- a/docs/design/alt.design/user-agent-refs.xml +++ b/docs/design/alt.design/user-agent-refs.xml @@ -14,792 +14,792 @@ <body> <s1 title="User Agent references in XSLFO"> <s2 title="4.9.2 Viewport Geometry"> - <p> - If the block-progression-dimension of the reference-area is - larger than that of the viewport-area and the overflow trait - for the reference-area is scroll, then the - inline-scroll-amount and block-scroll-amount are determined - by a scrolling mechanism, if any, provided by the - <strong>user agent</strong>. Otherwise, both are zero. - </p> + <p> + If the block-progression-dimension of the reference-area is + larger than that of the viewport-area and the overflow trait + for the reference-area is scroll, then the + inline-scroll-amount and block-scroll-amount are determined + by a scrolling mechanism, if any, provided by the + <strong>user agent</strong>. Otherwise, both are zero. + </p> </s2> <s2 title="5.1.3 Actual Values"> - <p> - A computed value is in principle ready to be used, but a - user agent may not be able to make use of the value in a - given environment. For example, a <strong>user - agent</strong> may only be able to render borders with - integer pixel widths and may, therefore, have to adjust the - computed width to an integral number of media pixels. - </p> + <p> + A computed value is in principle ready to be used, but a + user agent may not be able to make use of the value in a + given environment. For example, a <strong>user + agent</strong> may only be able to render borders with + integer pixel widths and may, therefore, have to adjust the + computed width to an integral number of media pixels. + </p> </s2> <s2 title="5.5.7 Font Properties"> - <p> - There is no XSL mechanism to specify a particular font; - instead, a selected font is chosen from the fonts available - to the <strong>User Agent</strong> based on a set of - selection criteria. The selection criteria are the following - font properties: "font-family", "font-style", - "font-variant", "font-weight", "font-stretch", and - "font-size", plus, for some formatting objects, one or more - characters. - </p> + <p> + There is no XSL mechanism to specify a particular font; + instead, a selected font is chosen from the fonts available + to the <strong>User Agent</strong> based on a set of + selection criteria. The selection criteria are the following + font properties: "font-family", "font-style", + "font-variant", "font-weight", "font-stretch", and + "font-size", plus, for some formatting objects, one or more + characters. + </p> </s2> <s2 title="5.9.13.1 Pixels"> - <p> - If the <strong>User Agent</strong> chooses a measurement for - a 'px' that does not match an integer number of device dots - in each axis it may produce undesirable effects... - </p> + <p> + If the <strong>User Agent</strong> chooses a measurement for + a 'px' that does not match an integer number of device dots + in each axis it may produce undesirable effects... + </p> </s2> <s2 title="5.10.4 Property Value Functions"> - <s3 title="Function: object merge-property-values( NCName)"> - <p> - The merge-property-values function returns a value of the - property whose name matches the argument, or if omitted - for the property for which the expression is being - evaluated. The value returned is the specified value on - the last fo:multi-property-set, of the parent - fo:multi-properties, that applies to the <strong>User - Agent</strong> state. If there is no such value, the - computed value of the parent fo:multi-properties is - returned... - </p> - <p> - The test for applicability of a <strong>User - Agent</strong> state is specified using the "active-state" - property. - </p> - </s3> + <s3 title="Function: object merge-property-values( NCName)"> + <p> + The merge-property-values function returns a value of the + property whose name matches the argument, or if omitted + for the property for which the expression is being + evaluated. The value returned is the specified value on + the last fo:multi-property-set, of the parent + fo:multi-properties, that applies to the <strong>User + Agent</strong> state. If there is no such value, the + computed value of the parent fo:multi-properties is + returned... + </p> + <p> + The test for applicability of a <strong>User + Agent</strong> state is specified using the "active-state" + property. + </p> + </s3> </s2> <s2 title="6.3 Formatting Objects Summary"> - <s3 title="multi-property-set"> - <p> - The fo:multi-property-set is used to specify an - alternative set of formatting properties that, dependent - on a <strong>User Agent</strong> state, are applied to the - content. - </p> - </s3> - <s3 title="title"> - <p> - The fo:title formatting object is used to associate a - title with a given page-sequence. This title may be used - by an interactive <strong>User Agent</strong> to identify - the pages. For example, the content of the fo:title can be - formatted and displayed in a "title" window or in a "tool - tip". - </p> - </s3> + <s3 title="multi-property-set"> + <p> + The fo:multi-property-set is used to specify an + alternative set of formatting properties that, dependent + on a <strong>User Agent</strong> state, are applied to the + content. + </p> + </s3> + <s3 title="title"> + <p> + The fo:title formatting object is used to associate a + title with a given page-sequence. This title may be used + by an interactive <strong>User Agent</strong> to identify + the pages. For example, the content of the fo:title can be + formatted and displayed in a "title" window or in a "tool + tip". + </p> + </s3> </s2> <s2 title="6.4.1.2 Page-masters"> - <p> - ... When pages are used with a <strong>User Agent</strong> - such as a Web browser, it is common that the each document - has only one page. The viewport used to view the page - determines the size of the page. When pages are placed on - non-interactive media, such as sheets of paper, pages - correspond to one or more of the surfaces of the paper. - </p> + <p> + ... When pages are used with a <strong>User Agent</strong> + such as a Web browser, it is common that the each document + has only one page. The viewport used to view the page + determines the size of the page. When pages are placed on + non-interactive media, such as sheets of paper, pages + correspond to one or more of the surfaces of the paper. + </p> </s2> <s2 title="6.4.20 fo:title"> - <s3 title="Common Usage:"> - <p> - ... This title may be used by an interactive <strong>User - Agent</strong> to identify the pages. - </p> - </s3> + <s3 title="Common Usage:"> + <p> + ... This title may be used by an interactive <strong>User + Agent</strong> to identify the pages. + </p> + </s3> </s2> <s2 title="6.6.3 fo:character"> - <s3 title="Constraints:"> - <p> - The dimensions of the areas are determined by the font - metrics for the glyph. - </p> - <p> - When formatting an fo:character with a - "treat-as-word-space" value of "true", the <strong>User - Agent</strong> may use a different method for determining - the inline-progression-dimension of the area. - </p> - </s3> + <s3 title="Constraints:"> + <p> + The dimensions of the areas are determined by the font + metrics for the glyph. + </p> + <p> + When formatting an fo:character with a + "treat-as-word-space" value of "true", the <strong>User + Agent</strong> may use a different method for determining + the inline-progression-dimension of the area. + </p> + </s3> </s2> <s2 title="6.9 Dynamic Effects: Link and Multi Formatting - Objects"> - <s3 title="6.9.1 Introduction"> - <p> - Dynamic effects, whereby user actions (including - <strong>User Agent</strong> state) can influence the - behavior and/or representation of portions of a document, - can be achieved through the use of the formatting objects - included in this section: - </p> - <ul> - <li>One-directional single-target links.</li> - <li> - The ability to switch between the display of two or more - formatting object subtrees. This can be used for, e.g., - expandable/collapsible table of contents, display of an - icon or a full table or graphic. - </li> - <li> - The ability to switch between different property values, - such as color or font-weight, depending on a - <strong>User Agent</strong> state, such as "hover". - </li> - </ul> - </s3> + Objects"> + <s3 title="6.9.1 Introduction"> + <p> + Dynamic effects, whereby user actions (including + <strong>User Agent</strong> state) can influence the + behavior and/or representation of portions of a document, + can be achieved through the use of the formatting objects + included in this section: + </p> + <ul> + <li>One-directional single-target links.</li> + <li> + The ability to switch between the display of two or more + formatting object subtrees. This can be used for, e.g., + expandable/collapsible table of contents, display of an + icon or a full table or graphic. + </li> + <li> + The ability to switch between different property values, + such as color or font-weight, depending on a + <strong>User Agent</strong> state, such as "hover". + </li> + </ul> + </s3> </s2> <s2 title="6.10 Out-of-Line Formatting Objects"> - <s3 title="6.10.1.3 Conditional Sub-Regions"> - <p> - ... There may be limits on how much space conditionally - generated areas can borrow from the - region-reference-area. It is left to the <strong>user - agent</strong> to decide these limits. - </p> - <p> - ... An interactive <strong>user agent</strong> may choose - to create "hot links" to the footnotes from the - footnote-citation, or create "hot links" to the - before-floats from an implicit citation, instead of - realizing conditional sub-regions. - </p> - </s3> + <s3 title="6.10.1.3 Conditional Sub-Regions"> + <p> + ... There may be limits on how much space conditionally + generated areas can borrow from the + region-reference-area. It is left to the <strong>user + agent</strong> to decide these limits. + </p> + <p> + ... An interactive <strong>user agent</strong> may choose + to create "hot links" to the footnotes from the + footnote-citation, or create "hot links" to the + before-floats from an implicit citation, instead of + realizing conditional sub-regions. + </p> + </s3> </s2> <s2 title="6.10.2 fo:float"> - <s3 title="Constraints:"> - <p> - ... The <strong>user agent</strong> may make its own - determination, after taking into account the intrusion - adjustments caused by one or more overlapping side-floats, - that the remaining space in the - inline-progression-direction is insufficient for the next - side-float or normal block-area. The <strong>user - agent</strong> may address this by causing the next - side-float or normal block-area to "clear" one of the - relevant side-floats, as described in the "clear" property - description, so the intrusion adjustment is sufficiently - reduced. Of the side-floats that could be cleared to meet - this constraint, the side-float that is actually cleared - must be the one whose after-edge is closest to the - before-edge of the parent reference-area. - </p> - <p> + <s3 title="Constraints:"> + <p> + ... The <strong>user agent</strong> may make its own + determination, after taking into account the intrusion + adjustments caused by one or more overlapping side-floats, + that the remaining space in the + inline-progression-direction is insufficient for the next + side-float or normal block-area. The <strong>user + agent</strong> may address this by causing the next + side-float or normal block-area to "clear" one of the + relevant side-floats, as described in the "clear" property + description, so the intrusion adjustment is sufficiently + reduced. Of the side-floats that could be cleared to meet + this constraint, the side-float that is actually cleared + must be the one whose after-edge is closest to the + before-edge of the parent reference-area. + </p> + <p> The <strong>user agent</strong> may determine sufficiency of space by using a fixed length, or by some heuristic such as whether an entire word fits into the available space, or by some combination, in order to handle text and images. - </p> - </s3> + </p> + </s3> </s2> <s2 title="6.10.3 fo:footnote"> - <s3 title="Constraints:"> - <p> - ... The second block-area and any additional block-areas - returned by an fo:footnote must be placed on the - immediately subsequent pages to the page containing the - first block-area returned by the fo:footnote, before any - other content is placed. If a subsequent page does not - contain a region-body, the <strong>user agent</strong> - must use the region-master of the last page that did - contain a region-body to hold the additional block-areas. - </p> - </s3> + <s3 title="Constraints:"> + <p> + ... The second block-area and any additional block-areas + returned by an fo:footnote must be placed on the + immediately subsequent pages to the page containing the + first block-area returned by the fo:footnote, before any + other content is placed. If a subsequent page does not + contain a region-body, the <strong>user agent</strong> + must use the region-master of the last page that did + contain a region-body to hold the additional block-areas. + </p> + </s3> </s2> <s2 title="7.3 Reference Rectangle for Percentage Computations"> - <p>...</p> - <s3 title="Exceptions ..."> - <p> - 5. When the absolute-position is "fixed", the containing - block is defined by the nearest ancestor viewport area. If - there is no ancestor viewport area, the containing block - is defined by the <strong>user agent</strong>. - </p> - </s3> + <p>...</p> + <s3 title="Exceptions ..."> + <p> + 5. When the absolute-position is "fixed", the containing + block is defined by the nearest ancestor viewport area. If + there is no ancestor viewport area, the containing block + is defined by the <strong>user agent</strong>. + </p> + </s3> </s2> <s2 title= - '7.6.5 "pause-after" 7.6.6 "pause-before" 7.6.17 "voice-family"'> - <p>Initial: depends on <strong>user agent</strong></p> + '7.6.5 "pause-after" 7.6.6 "pause-before" 7.6.17 "voice-family"'> + <p>Initial: depends on <strong>user agent</strong></p> </s2> <s2 title='7.7.1 "background-attachment"'> - <s3 title="fixed"> - <p> - ... <strong>User agents</strong> may treat fixed as - scroll. However, it is recommended they interpret fixed - correctly, at least for the HTML and BODY elements, since - there is no way for an author to provide an image only for - those browsers that support fixed. - </p> - </s3> + <s3 title="fixed"> + <p> + ... <strong>User agents</strong> may treat fixed as + scroll. However, it is recommended they interpret fixed + correctly, at least for the HTML and BODY elements, since + there is no way for an author to provide an image only for + those browsers that support fixed. + </p> + </s3> </s2> <s2 title='7.7.9 "border-before-width"'> - <s3 title="<length-conditional>"> - <p> - ... If border-before-width is specified using one of the - width keywords the .conditional component is set to - "discard" and the .length component to a <strong>User - Agent</strong> dependent length. - </p> - </s3> + <s3 title="<length-conditional>"> + <p> + ... If border-before-width is specified using one of the + width keywords the .conditional component is set to + "discard" and the .length component to a <strong>User + Agent</strong> dependent length. + </p> + </s3> </s2> <s2 title='7.7.19 "border-top-color"'> - <s3 title="<color>"> - <p> - ... If an element's border color is not specified with a - "border" property, <strong>user agents</strong> must use - the value of the element's "color" property as the - computed value for the border color. - </p> - </s3> + <s3 title="<color>"> + <p> + ... If an element's border color is not specified with a + "border" property, <strong>user agents</strong> must use + the value of the element's "color" property as the + computed value for the border color. + </p> + </s3> </s2> <s2 title='7.7.20 "border-top-style"'> - <p> - Conforming HTML <strong>user agents</strong> may interpret - 'dotted', 'dashed', 'double', 'groove', 'ridge', 'inset', - and 'outset' to be 'solid'. - </p> + <p> + Conforming HTML <strong>user agents</strong> may interpret + 'dotted', 'dashed', 'double', 'groove', 'ridge', 'inset', + and 'outset' to be 'solid'. + </p> </s2> <s2 title='7.7.21 "border-top-width"'> - <s3 title="thin ... medium ... thick ..."> - <p> - ... The interpretation of the first three values depends - on the <strong>user agent</strong>. - </p> - </s3> + <s3 title="thin ... medium ... thick ..."> + <p> + ... The interpretation of the first three values depends + on the <strong>user agent</strong>. + </p> + </s3> </s2> <s2 title='7.8.2 "font-family"'> - <p>Initial: depends on <strong>user agent</strong></p> + <p>Initial: depends on <strong>user agent</strong></p> </s2> <s2 title='7.8.3 "font-selection-strategy"'> - <p> - There is no XSL mechanism to specify a particular font; - instead, a selected font is chosen from the fonts available - to the <strong>User Agent</strong> based on a set of - selection criteria. The selection criteria are the following - font properties: "font-family", "font-style", - "font-variant", "font-weight", "font-stretch", and - "font-size", plus, for some formatting objects, one or more - characters. - </p> - <p> - ... This fallback may be to seek a match using a - <strong>User Agent</strong> default "font-family", or it may - be a more elaborate fallback strategy where, for example, - "Helvetica" would be used as a fallback for "Univers". - </p> - <p> - If no match has been found for a particular character, there - is no selected font and the <strong>User Agent</strong> - should provide a visual indication that a character is not - being displayed (for example, using the 'missing character' - glyph). - </p> + <p> + There is no XSL mechanism to specify a particular font; + instead, a selected font is chosen from the fonts available + to the <strong>User Agent</strong> based on a set of + selection criteria. The selection criteria are the following + font properties: "font-family", "font-style", + "font-variant", "font-weight", "font-stretch", and + "font-size", plus, for some formatting objects, one or more + characters. + </p> + <p> + ... This fallback may be to seek a match using a + <strong>User Agent</strong> default "font-family", or it may + be a more elaborate fallback strategy where, for example, + "Helvetica" would be used as a fallback for "Univers". + </p> + <p> + If no match has been found for a particular character, there + is no selected font and the <strong>User Agent</strong> + should provide a visual indication that a character is not + being displayed (for example, using the 'missing character' + glyph). + </p> </s2> <s2 title='7.8.4 "font-size"'> - <s3 title="<absolute-size>"> - <p> - An <absolute-size> keyword refers to an entry in a - table of font sizes computed and kept by the <strong>user - agent</strong>. Possible values are:<br/>[ xx-small | - x-small | small | medium | large | x-large | xx-large ] - </p> - </s3> - <s3 title="<relative-size>"> - <p> - A <relative-size> keyword is interpreted relative to - the table of font sizes and the font size of the parent - element. Possible values are:<br/>[ larger | smaller - ]<br/>For example, if the parent element has a font size - of "medium", a value of "larger" will make the font size - of the current element be "large". If the parent element's - size is not close to a table entry, the <strong>user - agent</strong> is free to interpolate between table - entries or round off to the closest one. The <strong>user - agent</strong> may have to extrapolate table values if the - numerical value goes beyond the keywords. - </p> - </s3> - <s3 title="<length>"> - <p> - A length value specifies an absolute font size (that is - independent of the <strong>user agent</strong>'s font - table). - </p> - </s3> + <s3 title="<absolute-size>"> + <p> + An <absolute-size> keyword refers to an entry in a + table of font sizes computed and kept by the <strong>user + agent</strong>. Possible values are:<br/>[ xx-small | + x-small | small | medium | large | x-large | xx-large ] + </p> + </s3> + <s3 title="<relative-size>"> + <p> + A <relative-size> keyword is interpreted relative to + the table of font sizes and the font size of the parent + element. Possible values are:<br/>[ larger | smaller + ]<br/>For example, if the parent element has a font size + of "medium", a value of "larger" will make the font size + of the current element be "large". If the parent element's + size is not close to a table entry, the <strong>user + agent</strong> is free to interpolate between table + entries or round off to the closest one. The <strong>user + agent</strong> may have to extrapolate table values if the + numerical value goes beyond the keywords. + </p> + </s3> + <s3 title="<length>"> + <p> + A length value specifies an absolute font size (that is + independent of the <strong>user agent</strong>'s font + table). + </p> + </s3> </s2> <s2 title='7.8.8 "font-variant"'> - <s3 title="small-caps"> - <p> - ... If a genuine small-caps font is not available, - <strong>user agents</strong> should simulate a small-caps - font... - </p> - </s3> + <s3 title="small-caps"> + <p> + ... If a genuine small-caps font is not available, + <strong>user agents</strong> should simulate a small-caps + font... + </p> + </s3> </s2> <s2 title='7.8.9 "font-weight"'> - <s3 title="XSL modifications to the CSS definition:"> - <p> - ... The association of other weights within a family to - the numerical weight values is intended only to preserve - the ordering of weights within that family. <strong>User - agents</strong> must map names to values in a way that - preserves visual order; a face mapped to a value must not - be lighter than faces mapped to lower values. There is no - guarantee on how a <strong>user agent</strong> will map - fonts within a family to weight values. However, the - following heuristics... - </p> - </s3> + <s3 title="XSL modifications to the CSS definition:"> + <p> + ... The association of other weights within a family to + the numerical weight values is intended only to preserve + the ordering of weights within that family. <strong>User + agents</strong> must map names to values in a way that + preserves visual order; a face mapped to a value must not + be lighter than faces mapped to lower values. There is no + guarantee on how a <strong>user agent</strong> will map + fonts within a family to weight values. However, the + following heuristics... + </p> + </s3> </s2> <s2 title='7.13.1 "alignment-adjust"'> - <s3 title="auto"> - <p> - ... If the baseline-identifier does not exist in the - baseline-table for the glyph or other inline-area, then - the <strong>User Agent</strong> may either use heuristics - to determine where that missing baseline would be or may - use the dominant-baseline as a fallback. - </p> - </s3> + <s3 title="auto"> + <p> + ... If the baseline-identifier does not exist in the + baseline-table for the glyph or other inline-area, then + the <strong>User Agent</strong> may either use heuristics + to determine where that missing baseline would be or may + use the dominant-baseline as a fallback. + </p> + </s3> </s2> <s2 title='7.13.3 "baseline-shift"'> - <s3 title="sub/super"> - <p> - ... Because in most fonts the subscript position is - normally given relative to the "alphabetic" baseline, the - <strong>User Agent</strong> may compute the effective - position for sub/superscripts <em>[sub: spec typo!]</em> - when some other baseline is dominant. ... If there is no - applicable font data the <strong>User Agent</strong> may - use heuristics to determine the offset. - </p> - </s3> + <s3 title="sub/super"> + <p> + ... Because in most fonts the subscript position is + normally given relative to the "alphabetic" baseline, the + <strong>User Agent</strong> may compute the effective + position for sub/superscripts <em>[sub: spec typo!]</em> + when some other baseline is dominant. ... If there is no + applicable font data the <strong>User Agent</strong> may + use heuristics to determine the offset. + </p> + </s3> </s2> <s2 title='7.13.5 "dominant-baseline"'> - <p> - ... If there is no baseline-table in the nominal font or if - the baseline-table lacks an entry for the desired baseline, - then the <strong>User Agent</strong> may use heuristics to - determine the position of the desired baseline. - </p> + <p> + ... If there is no baseline-table in the nominal font or if + the baseline-table lacks an entry for the desired baseline, + then the <strong>User Agent</strong> may use heuristics to + determine the position of the desired baseline. + </p> </s2> <s2 title='7.14.11 "scaling-method"'> - <s3 title="auto"> - <p> - The <strong>User Agent</strong> is free to choose either - resampling, integer scaling, or any other scaling method. - </p> - </s3> - <s3 title="integer-pixels"> - <p> - The <strong>User Agent</strong> should scale the image - such that each pixel in the original image is scaled to - the nearest integer number of device-pixels that yields an - image less-then-or-equal-to the image size derived from - the content-height, content-width, and scaling properties. - </p> - </s3> - <s3 title="resample-any-method"> - <p> - The <strong>User Agent</strong> should resample the - supplied image to provide an image that fills the size - derived from the content-height, content-width, and - scaling properties. The <strong>user agent</strong> may - use any sampling method. - </p> - </s3> - <p> - ... This is defined as a preference to allow the - <strong>user agent</strong> the flexibility to adapt to - device limitations and to accommodate over-constrained - situations involving min/max dimensions and scale factors. - </p> + <s3 title="auto"> + <p> + The <strong>User Agent</strong> is free to choose either + resampling, integer scaling, or any other scaling method. + </p> + </s3> + <s3 title="integer-pixels"> + <p> + The <strong>User Agent</strong> should scale the image + such that each pixel in the original image is scaled to + the nearest integer number of device-pixels that yields an + image less-then-or-equal-to the image size derived from + the content-height, content-width, and scaling properties. + </p> + </s3> + <s3 title="resample-any-method"> + <p> + The <strong>User Agent</strong> should resample the + supplied image to provide an image that fills the size + derived from the content-height, content-width, and + scaling properties. The <strong>user agent</strong> may + use any sampling method. + </p> + </s3> + <p> + ... This is defined as a preference to allow the + <strong>user agent</strong> the flexibility to adapt to + device limitations and to accommodate over-constrained + situations involving min/max dimensions and scale factors. + </p> </s2> <s2 title='7.14.12 "width"'> - <p> - ... The width of a replaced element's box is intrinsic and - may be scaled by the <strong>user agent </strong> if the - value of this property is different than 'auto'. - </p> + <p> + ... The width of a replaced element's box is intrinsic and + may be scaled by the <strong>user agent </strong> if the + value of this property is different than 'auto'. + </p> </s2> <s2 title='7.15.4 "line-height"'> - <s3 title="normal"> - <p> - Tells <strong>user agents</strong> to set the computed - value to a "reasonable" value based on the font size of - the element. - </p> - </s3> - <p> - ... When an element contains text that is rendered in more - than one font, <strong>user agents</strong> should determine - the "line-height" value according to the largest font size. - </p> + <s3 title="normal"> + <p> + Tells <strong>user agents</strong> to set the computed + value to a "reasonable" value based on the font size of + the element. + </p> + </s3> + <p> + ... When an element contains text that is rendered in more + than one font, <strong>user agents</strong> should determine + the "line-height" value according to the largest font size. + </p> </s2> <s2 title='7.15.9 "text-align"'> - <p> - ... The actual justification algorithm used is <strong>user - agent</strong> and written language dependent.<br/> - Conforming <strong>user agents</strong> may interpret the - value 'justify' as 'left' or 'right', depending on whether - the element's default writing direction is left-to-right or - right-to-left, respectively. - </p> + <p> + ... The actual justification algorithm used is <strong>user + agent</strong> and written language dependent.<br/> + Conforming <strong>user agents</strong> may interpret the + value 'justify' as 'left' or 'right', depending on whether + the element's default writing direction is left-to-right or + right-to-left, respectively. + </p> </s2> <s2 title='7.15.11 "text-indent"'> - <p> - ... <strong>User agents</strong> should render this - indentation as blank space. - </p> + <p> + ... <strong>User agents</strong> should render this + indentation as blank space. + </p> </s2> <s2 title='7.16.2 "letter-spacing"'> - <s3 title="normal"> - <p> - The spacing is the normal spacing for the current - font. This value allows the <strong>user agent</strong> to - alter the space between characters in order to justify - text. - </p> - </s3> - <s3 title="<length>"> - <p> - This value indicates inter-character space in addition to - the default space between characters. Values may be - negative, but there may be implementation-specific - limits. <strong>User agents</strong> may not further - increase or decrease the inter-character space in order to - justify text. - </p> - </s3> - <p> - Character-spacing algorithms are <strong>user agent</strong> - dependent. Character spacing may also be influenced by - justification (see the "text-align" property).<br/> When the - resultant space between two characters is not the same as - the default space, <strong>user agents</strong> should not - use ligatures.<br/> Conforming <strong>user agents</strong> - may consider the value of the 'letter-spacing' property to - be 'normal'. - </p> - <s3 title="XSL modifications to the CSS definition:"> - <p> - ... For "normal": .optimum = "the normal spacing for the - current font" / 2, .maximum = auto, .minimum = auto, - .precedence = force, and .conditionality = discard. A - value of auto for a component implies that the limits are - <strong>User Agent</strong> specific. - </p> - <p> - ... The CSS statement that "Conforming <strong>user - agents</strong> may consider the value of the - 'letter-spacing' property to be 'normal'." does not apply - in XSL, if the <strong>User Agent</strong> implements the - "Extended" property set. - </p> - <p> - ... The algorithm for resolving the adjusted values - between word spacing and letter spacing is <strong>User - Agent</strong> dependent. - </p> - </s3> + <s3 title="normal"> + <p> + The spacing is the normal spacing for the current + font. This value allows the <strong>user agent</strong> to + alter the space between characters in order to justify + text. + </p> + </s3> + <s3 title="<length>"> + <p> + This value indicates inter-character space in addition to + the default space between characters. Values may be + negative, but there may be implementation-specific + limits. <strong>User agents</strong> may not further + increase or decrease the inter-character space in order to + justify text. + </p> + </s3> + <p> + Character-spacing algorithms are <strong>user agent</strong> + dependent. Character spacing may also be influenced by + justification (see the "text-align" property).<br/> When the + resultant space between two characters is not the same as + the default space, <strong>user agents</strong> should not + use ligatures.<br/> Conforming <strong>user agents</strong> + may consider the value of the 'letter-spacing' property to + be 'normal'. + </p> + <s3 title="XSL modifications to the CSS definition:"> + <p> + ... For "normal": .optimum = "the normal spacing for the + current font" / 2, .maximum = auto, .minimum = auto, + .precedence = force, and .conditionality = discard. A + value of auto for a component implies that the limits are + <strong>User Agent</strong> specific. + </p> + <p> + ... The CSS statement that "Conforming <strong>user + agents</strong> may consider the value of the + 'letter-spacing' property to be 'normal'." does not apply + in XSL, if the <strong>User Agent</strong> implements the + "Extended" property set. + </p> + <p> + ... The algorithm for resolving the adjusted values + between word spacing and letter spacing is <strong>User + Agent</strong> dependent. + </p> + </s3> </s2> <s2 title='7.16.4 "text-decoration"'> - <p> - ... If the element has no content or no text content (e.g., - the IMG element in HTML), <strong>user agents</strong> must - ignore this property. - </p> - <s3 title="blink"> - <p> - ... Conforming <strong>user agents</strong> are not - required to support this value. - </p> - </s3> + <p> + ... If the element has no content or no text content (e.g., + the IMG element in HTML), <strong>user agents</strong> must + ignore this property. + </p> + <s3 title="blink"> + <p> + ... Conforming <strong>user agents</strong> are not + required to support this value. + </p> + </s3> </s2> <s2 title='7.16.6 "text-transform"'> - <p> - ... Conforming <strong>user agents</strong> may consider the - value of "text-transform" to be "none" for characters that - are not from the ISO Latin-1 repertoire and for elements in - languages for which the transformation is different from - that specified by the case-conversion tables of Unicode or - ISO 10646. - </p> + <p> + ... Conforming <strong>user agents</strong> may consider the + value of "text-transform" to be "none" for characters that + are not from the ISO Latin-1 repertoire and for elements in + languages for which the transformation is different from + that specified by the case-conversion tables of Unicode or + ISO 10646. + </p> </s2> <s2 title='7.16.8 "word-spacing"'> - <p> - ... Word spacing algorithms are <strong>user - agent</strong>-dependent. - </p> - <s3 title="XSL modifications to the CSS definition:"> - <p> - ... The algorithm for resolving the adjusted values - between word spacing and letter spacing is <strong>User - Agent</strong> dependent. - </p> - </s3> + <p> + ... Word spacing algorithms are <strong>user + agent</strong>-dependent. + </p> + <s3 title="XSL modifications to the CSS definition:"> + <p> + ... The algorithm for resolving the adjusted values + between word spacing and letter spacing is <strong>User + Agent</strong> dependent. + </p> + </s3> </s2> <s2 title='7.17.1 "color"'> - <p>Initial: depends on <strong>user agent</strong></p> + <p>Initial: depends on <strong>user agent</strong></p> </s2> <s2 title='7.17.3 "rendering-intent"'> - <s3 title="auto"> - <p> - This is the default behavior. The <strong>User - Agent</strong> determines the best intent based on the - content type. For image content containing an embedded - profile, it shall be assumed that the intent specified - within the profile is the desired intent. Otherwise, the - <strong>user agent</strong> shall use the current profile - and force the intent, overriding any intent that might be - stored in the profile itself. - </p> - </s3> + <s3 title="auto"> + <p> + This is the default behavior. The <strong>User + Agent</strong> determines the best intent based on the + content type. For image content containing an embedded + profile, it shall be assumed that the intent specified + within the profile is the desired intent. Otherwise, the + <strong>user agent</strong> shall use the current profile + and force the intent, overriding any intent that might be + stored in the profile itself. + </p> + </s3> </s2> <s2 title='7.20.2 "overflow"'> - <s3 title="scroll"> - <p> - This value indicates that the content is clipped and that - if the <strong>user agent</strong> uses a scrolling - mechanism that is visible on the screen (such as a scroll - bar or a panner), that mechanism should be displayed for a - box whether or not any of its content is clipped. - </p> - </s3> - <s3 title="auto"> - <p> - The behavior of the "auto" value is <strong>user - agent</strong> dependent, but should cause a scrolling - mechanism to be provided for overflowing boxes. - </p> - </s3> + <s3 title="scroll"> + <p> + This value indicates that the content is clipped and that + if the <strong>user agent</strong> uses a scrolling + mechanism that is visible on the screen (such as a scroll + bar or a panner), that mechanism should be displayed for a + box whether or not any of its content is clipped. + </p> + </s3> + <s3 title="auto"> + <p> + The behavior of the "auto" value is <strong>user + agent</strong> dependent, but should cause a scrolling + mechanism to be provided for overflowing boxes. + </p> + </s3> </s2> <s2 title='7.21.2 "leader-pattern"'> - <s3 title="dots"> - <p> - ... The choice of dot character is dependent on the - <strong>user agent</strong>. - </p> - </s3> + <s3 title="dots"> + <p> + ... The choice of dot character is dependent on the + <strong>user agent</strong>. + </p> + </s3> </s2> <s2 title='7.21.4 "leader-length"'> - <p> - ... <strong>User agents</strong> may choose to use the value - of "leader-length.optimum" to determine where to break the - line, then use the minimum and maximum values during line - justification. - </p> + <p> + ... <strong>User agents</strong> may choose to use the value + of "leader-length.optimum" to determine where to break the + line, then use the minimum and maximum values during line + justification. + </p> </s2> <s2 title='7.25.11 "media-usage"'> - <s3 title="auto"> - <p> - The <strong>User Agent</strong> determines which value of - "media-usage" (other than the "auto" value) is used. The - <strong>User Agent</strong> may consider the type of media - on which the presentation is to be placed in making this - determination.<br/> NOTE:<br/> For example, the - <strong>User Agent </strong> could use the following - decision process. If the media is not continuous and is of - fixed bounded size, then the "paginate" (described below) - is used. Otherwise, the "bounded-in-one-dimension" is - used. - </p> - </s3> - <s3 title="bounded-in-one-dimension"> - <p> - ... It is an error if more or less than one of - "page-height" or "page-width" is specified on the first - page master that is used. The <strong>User Agent</strong> - may recover as follows:... - </p> - </s3> - <s3 title="unbounded"> - <p> - Only one page is generated per fo:page-sequence descendant - from the fo:root. Neither "page-height" nor "page-width" - may be specified on any page master that is used. If a - value is specified for either property, it is an error and - a <strong>User Agent</strong> may recover by ignoring the - specified value. ... - </p> - </s3> + <s3 title="auto"> + <p> + The <strong>User Agent</strong> determines which value of + "media-usage" (other than the "auto" value) is used. The + <strong>User Agent</strong> may consider the type of media + on which the presentation is to be placed in making this + determination.<br/> NOTE:<br/> For example, the + <strong>User Agent </strong> could use the following + decision process. If the media is not continuous and is of + fixed bounded size, then the "paginate" (described below) + is used. Otherwise, the "bounded-in-one-dimension" is + used. + </p> + </s3> + <s3 title="bounded-in-one-dimension"> + <p> + ... It is an error if more or less than one of + "page-height" or "page-width" is specified on the first + page master that is used. The <strong>User Agent</strong> + may recover as follows:... + </p> + </s3> + <s3 title="unbounded"> + <p> + Only one page is generated per fo:page-sequence descendant + from the fo:root. Neither "page-height" nor "page-width" + may be specified on any page master that is used. If a + value is specified for either property, it is an error and + a <strong>User Agent</strong> may recover by ignoring the + specified value. ... + </p> + </s3> </s2> <s2 title='7.25.13 "page-height"'> - <s3 title="auto"> - <p> - The "page-height" shall be determined, in the case of - continuous media, from the size of the <strong>User - Agent</strong> window... - </p> - </s3> - <s3 title="NOTE:"> - <p> - A <strong>User Agent</strong> may provide a way to declare - the media for which formatting is to be done. This may be - different from the media on which the formatted result is - viewed. For example, a browser <strong>User Agent</strong> - may be used to preview pages that are formatted for sheet - media. In that case, the size calculation is based on the - media for which formatting is done rather than the media - being currently used. - </p> - </s3> + <s3 title="auto"> + <p> + The "page-height" shall be determined, in the case of + continuous media, from the size of the <strong>User + Agent</strong> window... + </p> + </s3> + <s3 title="NOTE:"> + <p> + A <strong>User Agent</strong> may provide a way to declare + the media for which formatting is to be done. This may be + different from the media on which the formatted result is + viewed. For example, a browser <strong>User Agent</strong> + may be used to preview pages that are formatted for sheet + media. In that case, the size calculation is based on the + media for which formatting is done rather than the media + being currently used. + </p> + </s3> </s2> <s2 title='7.25.15 "page-width"'> - <s3 title="auto"> - <p> - The "page-width" shall be determined, in the case of - continuous media, from the size of the <strong>User - Agent</strong> window... - </p> - </s3> + <s3 title="auto"> + <p> + The "page-width" shall be determined, in the case of + continuous media, from the size of the <strong>User + Agent</strong> window... + </p> + </s3> </s2> <s2 title='7.26.5 "border-separation"'> - <s3 title="<length-bp-ip-direction>"> - <p> - ... Rows, columns, row groups, and column groups cannot - have borders (i.e., <strong>user agents</strong> must - ignore the border properties for those elements). - </p> - </s3> + <s3 title="<length-bp-ip-direction>"> + <p> + ... Rows, columns, row groups, and column groups cannot + have borders (i.e., <strong>user agents</strong> must + ignore the border properties for those elements). + </p> + </s3> </s2> <s2 title='7.26.7 "caption-side"'> - <p> - ... For a caption that is on the left or right side of a - table box, on the other hand, a value other than "auto" for - "width" sets the width explicitly, but "auto" tells the - <strong>user agent</strong> to chose a "reasonable width". - </p> + <p> + ... For a caption that is on the left or right side of a + table box, on the other hand, a value other than "auto" for + "width" sets the width explicitly, but "auto" tells the + <strong>user agent</strong> to chose a "reasonable width". + </p> </s2> <s2 title='7.27.2 "glyph-orientation-horizontal"'> - <s3 title="<angle>"> - <p> - ... The <strong>User Agent</strong> shall round the value - of the angle to the closest of the permitted values. - </p> - </s3> + <s3 title="<angle>"> + <p> + ... The <strong>User Agent</strong> shall round the value + of the angle to the closest of the permitted values. + </p> + </s3> </s2> <s2 title='7.27.3 "glyph-orientation-vertical"'> - <s3 title="auto"> - <p> - ... The determination of which characters should be - auto-rotated may vary across <strong>User Agents</strong>. - </p> - </s3> - <s3 title="<angle>"> - <p> - ... The <strong>User Agent</strong> shall round the value - of the angle to the closest of the permitted values. - </p> - </s3> + <s3 title="auto"> + <p> + ... The determination of which characters should be + auto-rotated may vary across <strong>User Agents</strong>. + </p> + </s3> + <s3 title="<angle>"> + <p> + ... The <strong>User Agent</strong> shall round the value + of the angle to the closest of the permitted values. + </p> + </s3> </s2> <s2 title='7.27.6 "unicode-bidi"'> - <s3 title="XSL modifications to the CSS definition:"> - <p> - ... Fallback:<br/> If it is not possible to present the - characters in the correct order, then the - <strong>UserAgent </strong> should display either a - 'missing character' glyph or display some indication that - the content cannot be correctly rendered. - </p> - </s3> + <s3 title="XSL modifications to the CSS definition:"> + <p> + ... Fallback:<br/> If it is not possible to present the + characters in the correct order, then the + <strong>UserAgent </strong> should display either a + 'missing character' glyph or display some indication that + the content cannot be correctly rendered. + </p> + </s3> </s2> <s2 title='7.28.1 "content-type"'> - <p> - ... This property specifies the content-type and may be used - by a <strong>User Agent</strong> to select a rendering - processor for the object. - </p> - <s3 title="auto"> - <p> - No identification of the content-type. The <strong>User - Agent</strong> may determine it by "sniffing" or by other - means. - </p> - </s3> + <p> + ... This property specifies the content-type and may be used + by a <strong>User Agent</strong> to select a rendering + processor for the object. + </p> + <s3 title="auto"> + <p> + No identification of the content-type. The <strong>User + Agent</strong> may determine it by "sniffing" or by other + means. + </p> + </s3> </s2> <s2 title='7.29.5 "border-color"'> - <p> - ... If an element's border color is not specified with a - "border" property, <strong>user agents</strong> must use the - value of the element's "color" property as the computed - value for the border color. - </p> + <p> + ... If an element's border color is not specified with a + "border" property, <strong>user agents</strong> must use the + value of the element's "color" property as the computed + value for the border color. + </p> </s2> <s2 title='7.29.9 "border-spacing"'> - <p> - ... Rows, columns, row groups, and column groups cannot have - borders (i.e., <strong>user agents</strong> must ignore the - border properties for those elements). - </p> + <p> + ... Rows, columns, row groups, and column groups cannot have + borders (i.e., <strong>user agents</strong> must ignore the + border properties for those elements). + </p> </s2> <s2 title='7.29.13 "font"'> - <p> - ... If no font with the indicated characteristics exists on - a given platform, the <strong>user agent</strong> should - either intelligently substitute (e.g., a smaller version of - the "caption" font might be used for the "small-caption" - font), or substitute a <strong>user agent</strong> default - font. - </p> + <p> + ... If no font with the indicated characteristics exists on + a given platform, the <strong>user agent</strong> should + either intelligently substitute (e.g., a smaller version of + the "caption" font might be used for the "small-caption" + font), or substitute a <strong>user agent</strong> default + font. + </p> </s2> <s2 title='7.29.19 "pause"'> - <p>Initial: depends on <strong>user agent</strong></p> + <p>Initial: depends on <strong>user agent</strong></p> </s2> <s2 title='7.29.21 "size"'> - <p> - ... Relative page boxes allow <strong>user agents</strong> - to scale a document and make optimal use of the target size. - </p> - <p> - ... <strong>User agents</strong> may allow users to control - the transfer of the page box to the sheet (e.g., rotating an - absolute page box that's being printed). - </p> - <ul> - <li> - Rendering page boxes that do not fit a target sheet<br/> - If a page box does not fit the target sheet dimensions, - the <strong>user agent</strong> may choose to: - <ul> - <li> - Rotate the page box 90 degrees if this will make the - page box fit. - </li> - <li>Scale the page to fit the target.</li> - </ul> - The <strong>user agent</strong> should consult the user - before performing these operations. - </li> - <li> - Positioning the page box on the sheet<br/> When the page - box is smaller than the target size, the <strong>user - agent</strong> is free to place the page box anywhere on - the sheet. - </li> - </ul> + <p> + ... Relative page boxes allow <strong>user agents</strong> + to scale a document and make optimal use of the target size. + </p> + <p> + ... <strong>User agents</strong> may allow users to control + the transfer of the page box to the sheet (e.g., rotating an + absolute page box that's being printed). + </p> + <ul> + <li> + Rendering page boxes that do not fit a target sheet<br/> + If a page box does not fit the target sheet dimensions, + the <strong>user agent</strong> may choose to: + <ul> + <li> + Rotate the page box 90 degrees if this will make the + page box fit. + </li> + <li>Scale the page to fit the target.</li> + </ul> + The <strong>user agent</strong> should consult the user + before performing these operations. + </li> + <li> + Positioning the page box on the sheet<br/> When the page + box is smaller than the target size, the <strong>user + agent</strong> is free to place the page box anywhere on + the sheet. + </li> + </ul> </s2> <s2 title='7.29.23 "white-space"'> - <s3 title="normal"> - <p> - This value directs <strong>user agents</strong> to - collapse sequences of whitespace, and break lines as - necessary to fill line boxes. ... - </p> - </s3> - <s3 title="pre"> - <p> - This value prevents <strong>user agents</strong> from - collapsing sequences of whitespace. ... - </p> - </s3> - <p> - ... Conforming <strong>user agents</strong> may ignore the - 'white-space' property in author and user style sheets but - must specify a value for it in the default style sheet. - </p> + <s3 title="normal"> + <p> + This value directs <strong>user agents</strong> to + collapse sequences of whitespace, and break lines as + necessary to fill line boxes. ... + </p> + </s3> + <s3 title="pre"> + <p> + This value prevents <strong>user agents</strong> from + collapsing sequences of whitespace. ... + </p> + </s3> + <p> + ... Conforming <strong>user agents</strong> may ignore the + 'white-space' property in author and user style sheets but + must specify a value for it in the default style sheet. + </p> </s2> </s1> </body> diff --git a/docs/design/alt.design/xml-parsing.xml b/docs/design/alt.design/xml-parsing.xml index 240222352..4e7cf939d 100644 --- a/docs/design/alt.design/xml-parsing.xml +++ b/docs/design/alt.design/xml-parsing.xml @@ -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> diff --git a/docs/design/float.svg b/docs/design/float.svg index 7bef863a2..4e32f7203 100755 --- a/docs/design/float.svg +++ b/docs/design/float.svg @@ -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> diff --git a/docs/design/fo_impl/fo_classes.xml b/docs/design/fo_impl/fo_classes.xml index adcf04055..f9de1d683 100644 --- a/docs/design/fo_impl/fo_classes.xml +++ b/docs/design/fo_impl/fo_classes.xml @@ -72,289 +72,289 @@ parent. The Name, Spec Content, and Breaks & Keeps information is definite. The type and multiplicity of generated areas is definite, as well as whether the generated areas are reference areas or not. The BaseClass and the -layout area information is FOP-implementation dependent. +layout area information is FOP-implementation dependent. </para> <para><em>Note:</em> Numbers in parentheses refer to Notes. A * after an FO name indicates that the object is not yet implemented.</para> </usage> <category class="block-level"> <object> - <name>block</name> - <baseClass>FObjMixed</baseClass> - <specContent><![CDATA[(#PCDATA|%inline;|%block;)*]]></specContent> - <generatedAreas> - <type><class>normal</class><stacking>block</stacking></type> - <multiplicity>1..*</multiplicity> - <currentLayout>BlockArea</currentLayout> - </generatedAreas> - <breaksKeeps>All (2)</breaksKeeps> + <name>block</name> + <baseClass>FObjMixed</baseClass> + <specContent><![CDATA[(#PCDATA|%inline;|%block;)*]]></specContent> + <generatedAreas> + <type><class>normal</class><stacking>block</stacking></type> + <multiplicity>1..*</multiplicity> + <currentLayout>BlockArea</currentLayout> + </generatedAreas> + <breaksKeeps>All (2)</breaksKeeps> </object> <object> - <name>block-container</name> - <baseClass>FObj</baseClass> - <specContent><![CDATA[(%block;)+]]></specContent> - <generatedAreas isReference="true"> - <type><class>viewport/ref</class><stacking>block</stacking></type> - <multiplicity>1..*</multiplicity> - <currentLayout>AreaContainer</currentLayout> - </generatedAreas> - <breaksKeeps>All</breaksKeeps> + <name>block-container</name> + <baseClass>FObj</baseClass> + <specContent><![CDATA[(%block;)+]]></specContent> + <generatedAreas isReference="true"> + <type><class>viewport/ref</class><stacking>block</stacking></type> + <multiplicity>1..*</multiplicity> + <currentLayout>AreaContainer</currentLayout> + </generatedAreas> + <breaksKeeps>All</breaksKeeps> </object> <object implemented="false"> - <name>table-and-caption</name> - <baseClass>FObj (1)</baseClass> - <specContent>(table-caption?,table)</specContent> - <generatedAreas> - <type><class>normal</class><stacking>block</stacking></type> - <multiplicity>1..*</multiplicity> - <currentLayout>AreaContainer</currentLayout> - </generatedAreas> - <breaksKeeps>All keeps</breaksKeeps> + <name>table-and-caption</name> + <baseClass>FObj (1)</baseClass> + <specContent>(table-caption?,table)</specContent> + <generatedAreas> + <type><class>normal</class><stacking>block</stacking></type> + <multiplicity>1..*</multiplicity> + <currentLayout>AreaContainer</currentLayout> + </generatedAreas> + <breaksKeeps>All keeps</breaksKeeps> </object> <object> - <name>table</name> - <baseClass>FObj</baseClass> - <specContent>(table-column*,table-header?, table-footer?,table-body+)</specContent> - <generatedAreas isReference="true"> - <type><class>normal</class><stacking>block</stacking></type> - <multiplicity>1..*</multiplicity> - <currentLayout>AreaContainer</currentLayout> - </generatedAreas> - <breaksKeeps>All</breaksKeeps> + <name>table</name> + <baseClass>FObj</baseClass> + <specContent>(table-column*,table-header?, table-footer?,table-body+)</specContent> + <generatedAreas isReference="true"> + <type><class>normal</class><stacking>block</stacking></type> + <multiplicity>1..*</multiplicity> + <currentLayout>AreaContainer</currentLayout> + </generatedAreas> + <breaksKeeps>All</breaksKeeps> </object> <object> - <name>list-block</name> - <baseClass>FObj</baseClass> - <specContent>(list-item+)</specContent> - <generatedAreas> - <type><class>normal</class><stacking>block</stacking></type> - <multiplicity>1..*</multiplicity> - <currentLayout>BlockArea</currentLayout> - </generatedAreas> - <breaksKeeps>All</breaksKeeps> + <name>list-block</name> + <baseClass>FObj</baseClass> + <specContent>(list-item+)</specContent> + <generatedAreas> + <type><class>normal</class><stacking>block</stacking></type> + <multiplicity>1..*</multiplicity> + <currentLayout>BlockArea</currentLayout> + </generatedAreas> + <breaksKeeps>All</breaksKeeps> </object> </category> <category class="inline-level"> <object implemented="false"> - <name>bidi-override</name> - <baseClass>FObjMixed (1)</baseClass> - <specContent><![CDATA[(#PCDATA|%inline;|%block;)*]]></specContent> - <generatedAreas> - <type><class>normal</class><stacking>inline</stacking></type> - <multiplicity>1..*</multiplicity> - <currentLayout/> - </generatedAreas> - <breaksKeeps/> + <name>bidi-override</name> + <baseClass>FObjMixed (1)</baseClass> + <specContent><![CDATA[(#PCDATA|%inline;|%block;)*]]></specContent> + <generatedAreas> + <type><class>normal</class><stacking>inline</stacking></type> + <multiplicity>1..*</multiplicity> + <currentLayout/> + </generatedAreas> + <breaksKeeps/> </object> <object> - <name>character</name> - <baseClass>FObj</baseClass> - <specContent>EMPTY</specContent> - <generatedAreas> - <type><class>normal</class><stacking>inline</stacking></type> - <multiplicity>1</multiplicity> - <currentLayout intoParentArea="true">BlockArea</currentLayout> - </generatedAreas> - <breaksKeeps>kwn, kwp</breaksKeeps> + <name>character</name> + <baseClass>FObj</baseClass> + <specContent>EMPTY</specContent> + <generatedAreas> + <type><class>normal</class><stacking>inline</stacking></type> + <multiplicity>1</multiplicity> + <currentLayout intoParentArea="true">BlockArea</currentLayout> + </generatedAreas> + <breaksKeeps>kwn, kwp</breaksKeeps> </object> <object> - <name>external-graphic</name> - <baseClass>FObj</baseClass> - <specContent>EMPTY</specContent> - <generatedAreas> - <type><class>viewport/ref</class><stacking>inline</stacking></type> - <multiplicity>1</multiplicity> - <currentLayout>ImageArea</currentLayout> - </generatedAreas> - <breaksKeeps>kwn, kwp</breaksKeeps> + <name>external-graphic</name> + <baseClass>FObj</baseClass> + <specContent>EMPTY</specContent> + <generatedAreas> + <type><class>viewport/ref</class><stacking>inline</stacking></type> + <multiplicity>1</multiplicity> + <currentLayout>ImageArea</currentLayout> + </generatedAreas> + <breaksKeeps>kwn, kwp</breaksKeeps> </object> <object implemented="false"> - <name>initial-property-set</name> - <baseClass>FObj (1)</baseClass> - <specContent>EMPTY</specContent> - <generatedAreas/> - <breaksKeeps/> + <name>initial-property-set</name> + <baseClass>FObj (1)</baseClass> + <specContent>EMPTY</specContent> + <generatedAreas/> + <breaksKeeps/> </object> <object> - <name>instream-foreign-object</name> - <baseClass>FObj</baseClass> - <specContent>XML</specContent> - <generatedAreas> - <type><class>viewport/ref</class><stacking>inline</stacking></type> - <multiplicity>1</multiplicity> - <currentLayout>ForeignObjectArea</currentLayout> - </generatedAreas> - <breaksKeeps>kwn, kwp</breaksKeeps> + <name>instream-foreign-object</name> + <baseClass>FObj</baseClass> + <specContent>XML</specContent> + <generatedAreas> + <type><class>viewport/ref</class><stacking>inline</stacking></type> + <multiplicity>1</multiplicity> + <currentLayout>ForeignObjectArea</currentLayout> + </generatedAreas> + <breaksKeeps>kwn, kwp</breaksKeeps> </object> <object> - <name>inline</name> - <baseClass>FObjMixed</baseClass> - <specContent><![CDATA[(#PCDATA|%inline;|%block;)*]]></specContent> - <generatedAreas> - <type><class>normal</class><stacking>inline</stacking></type> - <multiplicity>1..*</multiplicity> - <currentLayout intoParentArea="true">Area</currentLayout> - </generatedAreas> - <breaksKeeps>All keeps</breaksKeeps> + <name>inline</name> + <baseClass>FObjMixed</baseClass> + <specContent><![CDATA[(#PCDATA|%inline;|%block;)*]]></specContent> + <generatedAreas> + <type><class>normal</class><stacking>inline</stacking></type> + <multiplicity>1..*</multiplicity> + <currentLayout intoParentArea="true">Area</currentLayout> + </generatedAreas> + <breaksKeeps>All keeps</breaksKeeps> </object> <object implemented="false"> - <name>inline-container</name> - <baseClass>FObj (1)</baseClass> - <specContent><![CDATA[(%block;)+]]></specContent> - <generatedAreas isReference="true"> - <type><class>viewport/ref</class><stacking>inline</stacking></type> - <multiplicity>1..*</multiplicity> - <currentLayout/> - </generatedAreas> - <breaksKeeps>All keeps</breaksKeeps> + <name>inline-container</name> + <baseClass>FObj (1)</baseClass> + <specContent><![CDATA[(%block;)+]]></specContent> + <generatedAreas isReference="true"> + <type><class>viewport/ref</class><stacking>inline</stacking></type> + <multiplicity>1..*</multiplicity> + <currentLayout/> + </generatedAreas> + <breaksKeeps>All keeps</breaksKeeps> </object> <object> - <name>leader</name> - <baseClass>FObjMixed</baseClass> - <specContent><![CDATA[(#PCDATA|%inline;)*]]></specContent> - <generatedAreas> - <type><class>normal</class><stacking>inline</stacking></type> - <multiplicity>1</multiplicity> - <currentLayout intoParentArea="true">BlockArea</currentLayout> - </generatedAreas> - <breaksKeeps/> + <name>leader</name> + <baseClass>FObjMixed</baseClass> + <specContent><![CDATA[(#PCDATA|%inline;)*]]></specContent> + <generatedAreas> + <type><class>normal</class><stacking>inline</stacking></type> + <multiplicity>1</multiplicity> + <currentLayout intoParentArea="true">BlockArea</currentLayout> + </generatedAreas> + <breaksKeeps/> </object> <object> - <name>page-number</name> - <baseClass>FObj</baseClass> - <specContent>EMPTY</specContent> - <generatedAreas> - <type><class>normal</class><stacking>inline</stacking></type> - <multiplicity>1</multiplicity> - <currentLayout intoParentArea="true">BlockArea (4)</currentLayout> - </generatedAreas> - <breaksKeeps>kwn, kwp</breaksKeeps> + <name>page-number</name> + <baseClass>FObj</baseClass> + <specContent>EMPTY</specContent> + <generatedAreas> + <type><class>normal</class><stacking>inline</stacking></type> + <multiplicity>1</multiplicity> + <currentLayout intoParentArea="true">BlockArea (4)</currentLayout> + </generatedAreas> + <breaksKeeps>kwn, kwp</breaksKeeps> </object> <object> - <name>page-number-citation</name> - <baseClass>FObj</baseClass> - <specContent>EMPTY</specContent> - <generatedAreas> - <type><class>normal</class><stacking>inline</stacking></type> - <multiplicity>1</multiplicity> - <currentLayout intoParentArea="true">BlockArea (4)</currentLayout> - </generatedAreas> - <breaksKeeps>kwn, kwp</breaksKeeps> + <name>page-number-citation</name> + <baseClass>FObj</baseClass> + <specContent>EMPTY</specContent> + <generatedAreas> + <type><class>normal</class><stacking>inline</stacking></type> + <multiplicity>1</multiplicity> + <currentLayout intoParentArea="true">BlockArea (4)</currentLayout> + </generatedAreas> + <breaksKeeps>kwn, kwp</breaksKeeps> </object> <object> - <name>basic-link</name> - <baseClass>FObjMixed</baseClass> - <specContent><![CDATA[(#PCDATA|%inline;|%block;)*]]></specContent> - <generatedAreas> - <type><class>normal</class><stacking>inline</stacking></type> - <multiplicity>1..*</multiplicity> - <currentLayout intoParentArea="true">Area (4)</currentLayout> - </generatedAreas> - <breaksKeeps>All keeps</breaksKeeps> + <name>basic-link</name> + <baseClass>FObjMixed</baseClass> + <specContent><![CDATA[(#PCDATA|%inline;|%block;)*]]></specContent> + <generatedAreas> + <type><class>normal</class><stacking>inline</stacking></type> + <multiplicity>1..*</multiplicity> + <currentLayout intoParentArea="true">Area (4)</currentLayout> + </generatedAreas> + <breaksKeeps>All keeps</breaksKeeps> </object> </category> <category class="other"> <object> - <name>list-item-body</name> - <baseClass>FObj</baseClass> - <specContent><![CDATA[(%block;)+]]></specContent> - <generatedAreas> - <type><class>None</class><stacking>None</stacking></type> - <multiplicity/> - <currentLayout intoParentArea="true">Area</currentLayout> - </generatedAreas> - <breaksKeeps>kt</breaksKeeps> + <name>list-item-body</name> + <baseClass>FObj</baseClass> + <specContent><![CDATA[(%block;)+]]></specContent> + <generatedAreas> + <type><class>None</class><stacking>None</stacking></type> + <multiplicity/> + <currentLayout intoParentArea="true">Area</currentLayout> + </generatedAreas> + <breaksKeeps>kt</breaksKeeps> </object> <object> - <name>list-item</name> - <baseClass>FObj</baseClass> - <specContent>(list-item-label,list-item-body)</specContent> - <generatedAreas> - <type><class>normal</class><stacking>block</stacking></type> - <multiplicity>1..*</multiplicity> - <currentLayout>BlockArea</currentLayout> - </generatedAreas> - <breaksKeeps>All</breaksKeeps> + <name>list-item</name> + <baseClass>FObj</baseClass> + <specContent>(list-item-label,list-item-body)</specContent> + <generatedAreas> + <type><class>normal</class><stacking>block</stacking></type> + <multiplicity>1..*</multiplicity> + <currentLayout>BlockArea</currentLayout> + </generatedAreas> + <breaksKeeps>All</breaksKeeps> </object> <object> - <name>list-item-label</name> - <baseClass>FObj</baseClass> - <specContent><![CDATA[(%block;)*]]></specContent> - <generatedAreas> - <type><class>None</class><stacking>None</stacking></type> - <multiplicity/> - <currentLayout intoParentArea="true">Area</currentLayout> - </generatedAreas> - <breaksKeeps>kt</breaksKeeps> + <name>list-item-label</name> + <baseClass>FObj</baseClass> + <specContent><![CDATA[(%block;)*]]></specContent> + <generatedAreas> + <type><class>None</class><stacking>None</stacking></type> + <multiplicity/> + <currentLayout intoParentArea="true">Area</currentLayout> + </generatedAreas> + <breaksKeeps>kt</breaksKeeps> </object> <object> - <name>table-body</name> - <baseClass>FObj</baseClass> - <specContent>(table-row+|table-cell+)</specContent> - <generatedAreas> - <type><class>None</class><stacking>None</stacking></type> - <multiplicity/> - <currentLayout>AreaContainer (3)</currentLayout> - </generatedAreas> - <breaksKeeps/> + <name>table-body</name> + <baseClass>FObj</baseClass> + <specContent>(table-row+|table-cell+)</specContent> + <generatedAreas> + <type><class>None</class><stacking>None</stacking></type> + <multiplicity/> + <currentLayout>AreaContainer (3)</currentLayout> + </generatedAreas> + <breaksKeeps/> </object> <object implemented="false"> - <name>table-caption</name> - <baseClass>FObj (1)</baseClass> - <specContent><![CDATA[(%block;)+]]></specContent> - <generatedAreas> - <type><class>normal</class><stacking>block</stacking></type> - <multiplicity>1..*</multiplicity> - <currentLayout/> - </generatedAreas> - <breaksKeeps>kt</breaksKeeps> + <name>table-caption</name> + <baseClass>FObj (1)</baseClass> + <specContent><![CDATA[(%block;)+]]></specContent> + <generatedAreas> + <type><class>normal</class><stacking>block</stacking></type> + <multiplicity>1..*</multiplicity> + <currentLayout/> + </generatedAreas> + <breaksKeeps>kt</breaksKeeps> </object> <object> - <name>table-cell</name> - <baseClass>FObj</baseClass> - <specContent><![CDATA[(%block;)+]]></specContent> - <generatedAreas isReference="true"> - <type><class>normal</class><stacking>block</stacking></type> - <multiplicity>1..*</multiplicity> - <currentLayout>AreaContainer</currentLayout> - </generatedAreas> - <breaksKeeps/> + <name>table-cell</name> + <baseClass>FObj</baseClass> + <specContent><![CDATA[(%block;)+]]></specContent> + <generatedAreas isReference="true"> + <type><class>normal</class><stacking>block</stacking></type> + <multiplicity>1..*</multiplicity> + <currentLayout>AreaContainer</currentLayout> + </generatedAreas> + <breaksKeeps/> </object> <object> - <name>table-column</name> - <baseClass>FObj</baseClass> - <specContent>EMPTY</specContent> - <generatedAreas/> - <breaksKeeps/> + <name>table-column</name> + <baseClass>FObj</baseClass> + <specContent>EMPTY</specContent> + <generatedAreas/> + <breaksKeeps/> </object> <object> - <name>table-footer</name> - <baseClass>TableBody</baseClass> - <specContent>(table-row+|table-cell+)</specContent> - <generatedAreas> - <type><class>None</class><stacking>None</stacking></type> - <multiplicity/> - <currentLayout>AreaContainer (3)</currentLayout> - </generatedAreas> - <breaksKeeps/> + <name>table-footer</name> + <baseClass>TableBody</baseClass> + <specContent>(table-row+|table-cell+)</specContent> + <generatedAreas> + <type><class>None</class><stacking>None</stacking></type> + <multiplicity/> + <currentLayout>AreaContainer (3)</currentLayout> + </generatedAreas> + <breaksKeeps/> </object> <object> - <name>table-header</name> - <baseClass>TableBody</baseClass> - <specContent>(table-row+|table-cell+)</specContent> - <generatedAreas> - <type><class>None</class><stacking>None</stacking></type> - <multiplicity/> - <currentLayout>AreaContainer (3)</currentLayout> - </generatedAreas> - <breaksKeeps/> + <name>table-header</name> + <baseClass>TableBody</baseClass> + <specContent>(table-row+|table-cell+)</specContent> + <generatedAreas> + <type><class>None</class><stacking>None</stacking></type> + <multiplicity/> + <currentLayout>AreaContainer (3)</currentLayout> + </generatedAreas> + <breaksKeeps/> </object> <object> - <name>table-row</name> - <baseClass>FObj</baseClass> - <specContent>(table-cell+)</specContent> - <generatedAreas/> - <breaksKeeps>All</breaksKeeps> + <name>table-row</name> + <baseClass>FObj</baseClass> + <specContent>(table-cell+)</specContent> + <generatedAreas/> + <breaksKeeps>All</breaksKeeps> </object> </category> <notes> diff --git a/docs/design/fo_impl/fo_classes.xsl b/docs/design/fo_impl/fo_classes.xsl index ad9e21690..bacb805df 100644 --- a/docs/design/fo_impl/fo_classes.xsl +++ b/docs/design/fo_impl/fo_classes.xsl @@ -1,14 +1,14 @@ -<?xml version="1.0"?> +<?xml version="1.0"?> <xsl:stylesheet - xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0" - xmlns:fo="http://www.w3.org/1999/XSL/Format"> - + xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0" + xmlns:fo="http://www.w3.org/1999/XSL/Format"> + <xsl:output method="html"/> <xsl:strip-space elements="*"/> <xsl:template match="/"> - <xsl:apply-templates/> + <xsl:apply-templates/> </xsl:template> <xsl:template match="formattingObjects"> @@ -31,69 +31,69 @@ </xsl:template> <xsl:template match="usage"> - <xsl:apply-templates select="para"/> + <xsl:apply-templates select="para"/> </xsl:template> <xsl:template match="para"> - <p><xsl:apply-templates/></p> + <p><xsl:apply-templates/></p> </xsl:template> <xsl:template match="em"> - <em><xsl:apply-templates/></em> + <em><xsl:apply-templates/></em> </xsl:template> <xsl:template match="term"> - <b><xsl:apply-templates/></b> + <b><xsl:apply-templates/></b> </xsl:template> <xsl:template match="category"> - <table width="100%" cellpadding="5" cellspacing="1" border="1"> - <tr> - <th>Name</th><th>Base Class</th><th>Spec Content</th> - <th>Generated Areas</th><th>Breaks and Keeps</th> - </tr> - <xsl:apply-templates select="object"/> - </table> + <table width="100%" cellpadding="5" cellspacing="1" border="1"> + <tr> + <th>Name</th><th>Base Class</th><th>Spec Content</th> + <th>Generated Areas</th><th>Breaks and Keeps</th> + </tr> + <xsl:apply-templates select="object"/> + </table> </xsl:template> <xsl:template match="object"> - <tr> - <td> - <xsl:value-of select="name"/> - <xsl:if test="self::node()[@implemented='false']"> *</xsl:if> - </td> - <td><xsl:value-of select="baseClass"/></td> - <td><xsl:value-of select="specContent"/></td> - <td><xsl:apply-templates select="generatedAreas"/></td> - <td><xsl:value-of select="breaksKeeps"/> </td> - </tr> + <tr> + <td> + <xsl:value-of select="name"/> + <xsl:if test="self::node()[@implemented='false']"> *</xsl:if> + </td> + <td><xsl:value-of select="baseClass"/></td> + <td><xsl:value-of select="specContent"/></td> + <td><xsl:apply-templates select="generatedAreas"/></td> + <td><xsl:value-of select="breaksKeeps"/> </td> + </tr> </xsl:template> <xsl:template match="generatedAreas"> <xsl:choose> - <xsl:when test="currentLayout"> - <ul> - <li>Class: <xsl:value-of select="type/class"/>  - Stacking: <xsl:value-of select="type/stacking"/></li> - <li>Multiplicity: <xsl:value-of select="multiplicity"/></li> - <li>Layout into: <xsl:value-of select="currentLayout"/> - <xsl:if test="currentLayout[@intoParentArea='true']"> (parent)</xsl:if></li> - <xsl:if test="self::node()[@isReference='true']"> - <li>Reference Area(s)</li> - </xsl:if> - </ul> - </xsl:when> - <xsl:otherwise> </xsl:otherwise> + <xsl:when test="currentLayout"> + <ul> + <li>Class: <xsl:value-of select="type/class"/>  + Stacking: <xsl:value-of select="type/stacking"/></li> + <li>Multiplicity: <xsl:value-of select="multiplicity"/></li> + <li>Layout into: <xsl:value-of select="currentLayout"/> + <xsl:if test="currentLayout[@intoParentArea='true']"> (parent)</xsl:if></li> + <xsl:if test="self::node()[@isReference='true']"> + <li>Reference Area(s)</li> + </xsl:if> + </ul> + </xsl:when> + <xsl:otherwise> </xsl:otherwise> </xsl:choose> </xsl:template> <xsl:template match="notes"> <p><b>Notes:</b></p> - <ol> - <xsl:for-each select="note"> - <li><xsl:value-of select="."/></li> - </xsl:for-each> - </ol> + <ol> + <xsl:for-each select="note"> + <li><xsl:value-of select="."/></li> + </xsl:for-each> + </ol> </xsl:template> </xsl:stylesheet> diff --git a/docs/design/page.svg b/docs/design/page.svg index 48b4a941a..f809cf749 100755 --- a/docs/design/page.svg +++ b/docs/design/page.svg @@ -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> |
