Browse Source
no longer needed, moved to src/documentation/content/xdocs/design/
git-svn-id: https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk@195704 13f79535-47bb-0310-9956-ffa450edef68tags/Alt-Design-integration-base
Keiron Liddle
21 years ago
60 changed files with 0 additions and 4717 deletions
BIN
docs/design/alt.design/AbsolutePosition.png
View File
+ 0
- 21
docs/design/alt.design/AbsolutePosition.png.xml
View File
| @@ -1,21 +0,0 @@ | |||
| <?xml version="1.0" encoding="ISO-8859-1"?> | |||
| <!-- $Id: AbsolutePosition.png.xml,v 1.1 2002-01-05 14:46:32+10 pbw | |||
| Exp pbw $ --> | |||
| <!-- | |||
| <!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd"> | |||
| --> | |||
| <document> | |||
| <header> | |||
| <title>AbsolutePosition diagram</title> | |||
| <authors> | |||
| <person id="pbw" name="Peter B. West" | |||
| email="pbwest@powerup.com.au"/> | |||
| </authors> | |||
| </header> | |||
| <body> | |||
| <!-- one of (anchor s1) --> | |||
| <s1 title="Properties$AbsolutePosition"> | |||
| <figure src="AbsolutePosition.png" alt="AbsolutePosition diagram"/> | |||
| </s1> | |||
| </body> | |||
| </document> | |||
BIN
docs/design/alt.design/BorderCommonStyle.png
View File
+ 0
- 20
docs/design/alt.design/BorderCommonStyle.png.xml
View File
| @@ -1,20 +0,0 @@ | |||
| <?xml version="1.0" encoding="ISO-8859-1"?> | |||
| <!-- $Id$ --> | |||
| <!-- | |||
| <!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd"> | |||
| --> | |||
| <document> | |||
| <header> | |||
| <title>BorderCommonStyle diagram</title> | |||
| <authors> | |||
| <person id="pbw" name="Peter B. West" | |||
| email="pbwest@powerup.com.au"/> | |||
| </authors> | |||
| </header> | |||
| <body> | |||
| <!-- one of (anchor s1) --> | |||
| <s1 title="Properties$BorderCommonStyle"> | |||
| <figure src="BorderCommonStyle.png" alt="BorderCommonStyle diagram"/> | |||
| </s1> | |||
| </body> | |||
| </document> | |||
BIN
docs/design/alt.design/PropNames.png
View File
+ 0
- 21
docs/design/alt.design/PropNames.png.xml
View File
| @@ -1,21 +0,0 @@ | |||
| <?xml version="1.0" encoding="ISO-8859-1"?> | |||
| <!-- $Id$ --> | |||
| <!-- | |||
| <!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd"> | |||
| --> | |||
| <document> | |||
| <header> | |||
| <title>..fo.PropNames diagram</title> | |||
| <authors> | |||
| <person id="pbw" name="Peter B. West" | |||
| email="pbwest@powerup.com.au"/> | |||
| </authors> | |||
| </header> | |||
| <body> | |||
| <!-- one of (anchor s1) --> | |||
| <s1 title="PropNames.class"> | |||
| <figure src="PropNames.png" alt="PropNames.class diagram"/> | |||
| </s1> | |||
| </body> | |||
| </document> | |||
BIN
docs/design/alt.design/Properties.png
View File
+ 0
- 21
docs/design/alt.design/Properties.png.xml
View File
| @@ -1,21 +0,0 @@ | |||
| <?xml version="1.0" encoding="ISO-8859-1"?> | |||
| <!-- $Id$ --> | |||
| <!-- | |||
| <!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd"> | |||
| --> | |||
| <document> | |||
| <header> | |||
| <title>..fo.Properties diagram</title> | |||
| <authors> | |||
| <person id="pbw" name="Peter B. West" | |||
| email="pbwest@powerup.com.au"/> | |||
| </authors> | |||
| </header> | |||
| <body> | |||
| <!-- one of (anchor s1) --> | |||
| <s1 title="Properties.class"> | |||
| <figure src="Properties.png" alt="Properties.class diagram"/> | |||
| </s1> | |||
| </body> | |||
| </document> | |||
BIN
docs/design/alt.design/PropertyClasses.png
View File
BIN
docs/design/alt.design/PropertyConsts.png
View File
+ 0
- 20
docs/design/alt.design/PropertyConsts.png.xml
View File
| @@ -1,20 +0,0 @@ | |||
| <?xml version="1.0" encoding="ISO-8859-1"?> | |||
| <!-- $Id$ --> | |||
| <!-- | |||
| <!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd"> | |||
| --> | |||
| <document> | |||
| <header> | |||
| <title>..fo.PropertyConsts diagram</title> | |||
| <authors> | |||
| <person id="pbw" name="Peter B. West" | |||
| email="pbwest@powerup.com.au"/> | |||
| </authors> | |||
| </header> | |||
| <body> | |||
| <!-- one of (anchor s1) --> | |||
| <s1 title="PropertyConsts.class"> | |||
| <figure src="PropertyConsts.png" alt="PropertyConsts.class diagram"/> | |||
| </s1> | |||
| </body> | |||
| </document> | |||
BIN
docs/design/alt.design/PropertyStaticsOverview.png
View File
BIN
docs/design/alt.design/SAXParsing.png
View File
BIN
docs/design/alt.design/VerticalAlign.png
View File
+ 0
- 21
docs/design/alt.design/VerticalAlign.png.xml
View File
| @@ -1,21 +0,0 @@ | |||
| <?xml version="1.0" encoding="ISO-8859-1"?> | |||
| <!-- $Id$ --> | |||
| <!-- | |||
| <!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd"> | |||
| --> | |||
| <document> | |||
| <header> | |||
| <title>VerticalAlign diagram</title> | |||
| <authors> | |||
| <person id="pbw" name="Peter B. West" | |||
| email="pbwest@powerup.com.au"/> | |||
| </authors> | |||
| </header> | |||
| <body> | |||
| <!-- one of (anchor s1) --> | |||
| <s1 title="Properties$VerticalAlign"> | |||
| <figure src="VerticalAlign.png" alt="VerticalAlign diagram"/> | |||
| </s1> | |||
| </body> | |||
| </document> | |||
BIN
docs/design/alt.design/XML-event-buffer.png
View File
BIN
docs/design/alt.design/XMLEventQueue.png
View File
+ 0
- 167
docs/design/alt.design/alt.properties.xml
View File
| @@ -1,167 +0,0 @@ | |||
| <?xml version="1.0" encoding="ISO-8859-1"?> | |||
| <!-- $Id$ --> | |||
| <!-- | |||
| <!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd"> | |||
| --> | |||
| <document> | |||
| <header> | |||
| <title>Implementing Properties</title> | |||
| <authors> | |||
| <person id="pbw" name="Peter B. West" email="pbwest@powerup.com.au"/> | |||
| </authors> | |||
| </header> | |||
| <body> | |||
| <!-- 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. | |||
| </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. | |||
| </p> | |||
| <note> | |||
| <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. | |||
| </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. | |||
| </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. | |||
| </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. | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </s2> | |||
| <p> | |||
| <strong>Next:</strong> <link href= "classes-overview.html" | |||
| >property classes overview.</link> | |||
| </p> | |||
| </s1> | |||
| </body> | |||
| </document> | |||
BIN
docs/design/alt.design/block-stacking-constraints.png
View File
BIN
docs/design/alt.design/block-stacking-keeps.png
View File
BIN
docs/design/alt.design/block-stacking.png
View File
+ 0
- 32
docs/design/alt.design/book.xml
View File
| @@ -1,32 +0,0 @@ | |||
| <?xml version="1.0"?> | |||
| <book title="FOP New Design Notes" copyright="2001-2002 The Apache Software Foundation"> | |||
| <external href="http://xml.apache.org/fop/" label="About FOP"/> | |||
| <separator/> | |||
| <external href="../index.html" label="NEW DESIGN" /> | |||
| <separator/> | |||
| <page id="index" label="Alt Design" source="intro.xml"/> | |||
| <page id="co-routines" label="co-routines" source="coroutines.xml"/> | |||
| <page id="galleys" label="galleys" source="galleys.xml"/> | |||
| <page id="footnotes" label="footnotes" source="footnotes.xml"/> | |||
| <page id="keeps" label="keeps" source="keeps.xml"/> | |||
| <page id="spaces" label="space-specifiers" source="spaces.xml"/> | |||
| <separator/> | |||
| <page id="alt.properties" label="alt.properties" source="alt.properties.xml"/> | |||
| <page id="classes-overview" label="Classes overview" source="classes-overview.xml"/> | |||
| <page id="properties-classes" label="Properties classes" source="properties-classes.xml"/> | |||
| <page id="Properties" label="Properties" source="Properties.png.xml"/> | |||
| <page id="PropertyConsts" label="PropertyConsts" source="PropertyConsts.png.xml"/> | |||
| <page id="PropNames" label="PropNames" source="PropNames.png.xml"/> | |||
| <page id="AbsolutePosition" label="AbsolutePosition" source="AbsolutePosition.png.xml"/> | |||
| <page id="VerticalAlign" label="VerticalAlign" source="VerticalAlign.png.xml"/> | |||
| <page id="BorderCommonStyle" label="BorderCommonStyle" source="BorderCommonStyle.png.xml"/> | |||
| <separator/> | |||
| <page id="xml-parsing" label="XML parsing" source="xml-parsing.xml"/> | |||
| <separator/> | |||
| <page id="property-parsing" label="Property parsing" source="propertyExpressions.xml"/> | |||
| <separator/> | |||
| <page id="compound-properties" label="Compound properties" source="compound-properties.xml"/> | |||
| <page id="traits" label="Traits" source="traits.xml"/> | |||
| <page id="user-agent-refs" label="User agent refs" source="user-agent-refs.xml"/> | |||
| </book> | |||
+ 0
- 201
docs/design/alt.design/classes-overview.xml
View File
| @@ -1,201 +0,0 @@ | |||
| <?xml version="1.0" encoding="ISO-8859-1"?> | |||
| <!-- $Id$ --> | |||
| <!-- | |||
| <!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd"> | |||
| --> | |||
| <document> | |||
| <header> | |||
| <title>Property classes overview</title> | |||
| <authors> | |||
| <person id="pbw" name="Peter B. West" | |||
| 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> | |||
| </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> | |||
| </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> | |||
| </s2> | |||
| <p> | |||
| <strong>Previous:</strong> <link href= | |||
| "alt.properties.html" >alt.properties</link> | |||
| </p> | |||
| <p> | |||
| <strong>Next:</strong> <link href= | |||
| "properties-classes.html" >Properties classes</link> | |||
| </p> | |||
| </s1> | |||
| </body> | |||
| </document> | |||
+ 0
- 218
docs/design/alt.design/compound-properties.xml
View File
| @@ -1,218 +0,0 @@ | |||
| <?xml version="1.0" encoding="ISO-8859-1"?> | |||
| <!-- $Id$ --> | |||
| <!-- | |||
| <!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd"> | |||
| --> | |||
| <document> | |||
| <header> | |||
| <title>Compound properties</title> | |||
| <authors> | |||
| <person name="Peter B. West" email="pbwest@powerup.com.au"/> | |||
| </authors> | |||
| </header> | |||
| <body> | |||
| <s1 title="Compound properties in XSLFO"> | |||
| <table> | |||
| <tr> | |||
| <th>Property type</th> | |||
| <th>Section</th> | |||
| <th>Inherited</th> | |||
| <th>'inherit'</th> | |||
| </tr> | |||
| <tr> | |||
| <th><length-range></th> | |||
| </tr> | |||
| <tr> | |||
| <th>minimum</th> | |||
| </tr> | |||
| <tr> | |||
| <th>optimum</th> | |||
| </tr> | |||
| <tr> | |||
| <th>maximum</th> | |||
| </tr> | |||
| <tr> | |||
| <td>block-progression-dimension</td> | |||
| <td>7.14.1</td> | |||
| <td>no</td> | |||
| <td>yes</td> | |||
| </tr> | |||
| <tr> | |||
| <td>inline-progression-dimension</td> | |||
| <td>7.14.5</td> | |||
| <td>no</td> | |||
| <td>yes</td> | |||
| </tr> | |||
| <tr> | |||
| <td>leader-length</td> | |||
| <td>7.21.4</td> | |||
| <td>yes</td> | |||
| <td>yes</td> | |||
| </tr> | |||
| <tr> | |||
| <th><length-conditional></th> | |||
| </tr> | |||
| <tr> | |||
| <th>length</th> | |||
| </tr> | |||
| <tr> | |||
| <th>conditionality</th> | |||
| </tr> | |||
| <tr> | |||
| <td>border-after-width</td> | |||
| <td>7.7.12</td> | |||
| <td>no</td> | |||
| <td>yes</td> | |||
| </tr> | |||
| <tr> | |||
| <td>border-before-width</td> | |||
| <td>7.7.9</td> | |||
| <td>no</td> | |||
| <td>yes</td> | |||
| </tr> | |||
| <tr> | |||
| <td>border-end-width</td> | |||
| <td>7.7.18</td> | |||
| <td>no</td> | |||
| <td>yes</td> | |||
| </tr> | |||
| <tr> | |||
| <td>border-start-width</td> | |||
| <td>7.7.15</td> | |||
| <td>no</td> | |||
| <td>yes</td> | |||
| </tr> | |||
| <tr> | |||
| <td>padding-after</td> | |||
| <td>7.7.32</td> | |||
| <td>no</td> | |||
| <td>yes</td> | |||
| </tr> | |||
| <tr> | |||
| <td>padding-before</td> | |||
| <td>7.7.31</td> | |||
| <td>no</td> | |||
| <td>yes</td> | |||
| </tr> | |||
| <tr> | |||
| <td>padding-end</td> | |||
| <td>7.7.34</td> | |||
| <td>no</td> | |||
| <td>yes</td> | |||
| </tr> | |||
| <tr> | |||
| <td>padding-start</td> | |||
| <td>7.7.33</td> | |||
| <td>no</td> | |||
| <td>yes</td> | |||
| </tr> | |||
| <tr> | |||
| <th><length-bp-ip-direction></th> | |||
| </tr> | |||
| <tr> | |||
| <th>block-progression-direction</th> | |||
| </tr> | |||
| <tr> | |||
| <th>inline-progression-direction</th> | |||
| </tr> | |||
| <tr> | |||
| <td>border-separation</td> | |||
| <td>7.26.5</td> | |||
| <td>yes</td> | |||
| <td>yes</td> | |||
| </tr> | |||
| <tr> | |||
| <th><space></th> | |||
| </tr> | |||
| <tr> | |||
| <th>minimum</th> | |||
| </tr> | |||
| <tr> | |||
| <th>optimum</th> | |||
| </tr> | |||
| <tr> | |||
| <th>maximum</th> | |||
| </tr> | |||
| <tr> | |||
| <th>precedence</th> | |||
| </tr> | |||
| <tr> | |||
| <th>conditionality</th> | |||
| </tr> | |||
| <tr> | |||
| <td>letter-spacing</td> | |||
| <td>7.16.2</td> | |||
| <td>yes</td> | |||
| <td>yes</td> | |||
| </tr> | |||
| <tr> | |||
| <td>line-height</td> | |||
| <td>7.15.4</td> | |||
| <td>yes</td> | |||
| <td>yes</td> | |||
| </tr> | |||
| <tr> | |||
| <td>space-after</td> | |||
| <td>7.10.6</td> | |||
| <td>no</td> | |||
| <td>yes</td> | |||
| </tr> | |||
| <tr> | |||
| <td>space-before</td> | |||
| <td>7.10.5</td> | |||
| <td>no</td> | |||
| <td>yes</td> | |||
| </tr> | |||
| <tr> | |||
| <td>space-end</td> | |||
| <td>7.11.1</td> | |||
| <td>no</td> | |||
| <td>yes</td> | |||
| </tr> | |||
| <tr> | |||
| <td>space-start</td> | |||
| <td>7.11.2</td> | |||
| <td>no</td> | |||
| <td>yes</td> | |||
| </tr> | |||
| <tr> | |||
| <td>word-spacing</td> | |||
| <td>7.16.8</td> | |||
| <td>yes</td> | |||
| <td>yes</td> | |||
| </tr> | |||
| <tr> | |||
| <th><keep></th> | |||
| </tr> | |||
| <tr> | |||
| <th>within-line</th> | |||
| </tr> | |||
| <tr> | |||
| <th>within-column</th> | |||
| </tr> | |||
| <tr> | |||
| <th>within-page</th> | |||
| </tr> | |||
| <tr> | |||
| <td>keep-together</td> | |||
| <td>7.19.3</td> | |||
| <td>yes</td> | |||
| <td>yes</td> | |||
| </tr> | |||
| <tr> | |||
| <td>keep-with-next</td> | |||
| <td>7.19.4</td> | |||
| <td>no</td> | |||
| <td>yes</td> | |||
| </tr> | |||
| <tr> | |||
| <td>keep-with-previous</td> | |||
| <td>7.19.5</td> | |||
| <td>no</td> | |||
| <td>yes</td> | |||
| </tr> | |||
| </table> | |||
| </s1> | |||
| </body> | |||
| </document> | |||
BIN
docs/design/alt.design/coroutines.png
View File
+ 0
- 118
docs/design/alt.design/coroutines.xml
View File
| @@ -1,118 +0,0 @@ | |||
| <?xml version="1.0" encoding="ISO-8859-1"?> | |||
| <!-- $Id$ --> | |||
| <!-- | |||
| <!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd"> | |||
| --> | |||
| <document> | |||
| <header> | |||
| <title>Implementing co-routines</title> | |||
| <authors> | |||
| <person name="Peter B. West" email="pbwest@powerup.com.au"/> | |||
| </authors> | |||
| </header> | |||
| <body> | |||
| <!-- one of (anchor s1) --> | |||
| <s1 title="Implementing Co-routines in FOP"> | |||
| <p> | |||
| All general page layout systems have to solve the same | |||
| fundamental problem: expressing a flow of text with its own | |||
| natural structure as a series of pages corresponding to the | |||
| physical and logical structure of the output medium. This | |||
| simple description disguises many complexities. Version 1.0 | |||
| of the Recommendation, in Section 3, <em>Introduction to | |||
| Formatting </em>, includes the following comments. | |||
| </p> | |||
| <note> | |||
| [Formatting] comprises several steps, some of which depend on | |||
| others in a non-sequential way.<br/> ...and...<br/> | |||
| [R]efinement is not necessarily a straightforward, sequential | |||
| procedure, but may involve look-ahead, back-tracking, or | |||
| control-splicing with other processes in the formatter. | |||
| </note> | |||
| <p>Section 3.1, <em>Conceptual Procedure</em>, includes:</p> | |||
| <note> | |||
| The procedure works by processing formatting objects. Each | |||
| object, while being processed, may initiate processing in | |||
| other objects. While the objects are hierarchically | |||
| structured, the processing is not; processing of a given | |||
| object is rather like a co-routine which may pass control to | |||
| other processes, but pick up again later where it left off. | |||
| </note> | |||
| <s2 title="Application of co-routines"> | |||
| <p> | |||
| If one looks only at the flow side of the equation, it's | |||
| difficult to see what the problem might be. The ordering of | |||
| the elements of the flow is preserved in the area tree, and | |||
| where elements are in an hierarchical relationship in the | |||
| flow, they will generally be in an hierarchical relationship | |||
| in the area tree. In such circumstances, the recursive | |||
| processing of the flow seems quite natural. | |||
| </p> | |||
| <p> | |||
| The problem becomes more obvious when one thinks about the | |||
| imposition of an unrelated page structure over the | |||
| hierarchical structure of the document content. Take, e.g., | |||
| the processing of a nested flow structure which, at a certain | |||
| point, is scanning text and generating line-areas, nested | |||
| within other block areas and possibly other line areas. The | |||
| page fills in the middle of this process. Processing at the | |||
| lowest level in the tree must now suspend, immediately | |||
| following the production of the line-area which filled the | |||
| page. This same event, however, must also trigger the closing | |||
| and flushing to the area tree of every open area of which the last | |||
| line-area was a descendant. | |||
| </p> | |||
| <p> | |||
| Once all of these areas have been closed, some dormant process | |||
| or processes must wake up, flush the area sub-tree | |||
| representing the page, and open a new page sub-tree in the | |||
| area tree. Then the whole nested structure of flow objects | |||
| and area production must be re-activated, at the point in | |||
| processing at which the areas of the previous page were | |||
| finalised, but with the new page environment. The most | |||
| natural way of expressing the temporal relationship of these | |||
| processes is by means of co-routines. | |||
| </p> | |||
| <p> | |||
| Normal sub-routines (methods) display a hierarchical | |||
| relationship where process A suspends on invoking process B, | |||
| which on termination returns control to A which resumes from | |||
| the point of suspension. Co-routines instead have a parallel | |||
| relationship. Process A suspends on invoking process B, but | |||
| process B also suspends on returning control to process A. To | |||
| process B, this return of control appears to be an invocation | |||
| of process A. When process A subsequently invokes B and | |||
| suspends, B behaves as though its previous invocation of A has | |||
| returned, and it resumes from the point of that invocation. | |||
| So control bounces between the two, each one resuming where it | |||
| left off.<br/><br/> | |||
| <strong>Figure 1</strong> | |||
| </p> | |||
| <figure src="coroutines.png" alt="Co-routine diagram"/> | |||
| <p> | |||
| For example, think of a page-production method working on a | |||
| complex page-sequence-master. | |||
| </p> | |||
| <source> | |||
| void makePages(...) { | |||
| ... | |||
| while (pageSequence.hasNext()) { | |||
| ... | |||
| page = generateNextPage(...); | |||
| boolean over = flow.fillPage(page); | |||
| if (over) return; | |||
| } | |||
| } | |||
| </source> | |||
| <p> | |||
| The <code>fillPage()</code> method, when it fills a page, will | |||
| have unfinished business with the flow, which it will want to | |||
| resume at the next call; hence co-routines. One way to | |||
| implement them in Java is by threads synchronised on some | |||
| common argument-passing object. | |||
| </p> | |||
| </s2> | |||
| </s1> | |||
| </body> | |||
| </document> | |||
+ 0
- 137
docs/design/alt.design/footnotes.xml
View File
| @@ -1,137 +0,0 @@ | |||
| <?xml version="1.0" encoding="ISO-8859-1"?> | |||
| <!-- $Id$ --> | |||
| <!-- | |||
| <!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd"> | |||
| --> | |||
| <document> | |||
| <header> | |||
| <title>Implementing footnotes</title> | |||
| <authors> | |||
| <person name="Peter B. West" email="pbwest@powerup.com.au"/> | |||
| </authors> | |||
| </header> | |||
| <body> | |||
| <!-- one of (anchor s1) --> | |||
| <s1 title="Implementing footnotes in FOP"> | |||
| <p> | |||
| Footnotes present difficulties for page layout primarily | |||
| because their point of invocation in the flow is different | |||
| from their point of appearance in the area tree. All of the | |||
| content lines of a footnote may appear on the same page as its | |||
| invocation point, all may appear on a following page, or the | |||
| lines may be split over a page or pages. (This characteristic | |||
| leads to another problem when a footnote overflows the last | |||
| page of flow content, but that difficulty will not be | |||
| discussed here.) This note considers some aspects of the | |||
| implementation of footnotes in a galley-based design. | |||
| </p> | |||
| <s2 title="Footnotes and galleys"> | |||
| <p> | |||
| In the structure described in the <link href= | |||
| "../galleys.html" >introduction to FOP galleys</link>, | |||
| footnotes would be pre-processed as galleys themselves, but | |||
| they would remain attached as subtrees to their points of | |||
| invocation in the main text. Allocation to a | |||
| footnote-reference-area would only occur in the resolution | |||
| to Area nodes. | |||
| </p> | |||
| <p> | |||
| When footnotes are introduced, the communication between | |||
| galleys and layout manager, as mentioned <link href= | |||
| "../galleys.html#pre-processing" >above</link>, would be | |||
| affected. The returned information would two b-p-d values: | |||
| the primary line-area b-p-d impact and the footnote b-p-d | |||
| impact. The distinction is necessary for two reasons; to | |||
| alert the layout manager to the first footnote of the page, | |||
| and because the footnote b-p-d will always impact the | |||
| main-reference-area b-p-d, whereas the primary inline-area | |||
| may not, e.g. in the case of multiple span-areas. | |||
| </p> | |||
| </s2> | |||
| <s2 title="Multiple columns and footnotes"> | |||
| <note> | |||
| A possible method for multi-column layout and balancing | |||
| with footnotes, using a galley-based approach. | |||
| </note> | |||
| <p> | |||
| This note assumes a galley, as discussed <link href= | |||
| "../galleys.html" >elsewhere</link>, flowing text with | |||
| footnotes and possibly other blocks into a possibly | |||
| multi-column area. The logic of flowing into multiple | |||
| columns is trivially applied to a single column. The galley | |||
| is manipulated within the context of the <em>layout | |||
| tree</em>. | |||
| </p> | |||
| <p> | |||
| Associated with the galley are two sets of data. | |||
| One contains the maps of all "natural" break-points and | |||
| the of all hyphenation break-points. This set is | |||
| constructed at the time of construction of the galley and | |||
| is a constant for a given galley. The second contains | |||
| dynamic data which represents one possible attempt to lay | |||
| out the galley. There may be multiple sets of such data | |||
| to reflect varying attempts. The data of this set are, | |||
| essentially, representations of line-areas, with the supporting | |||
| information necessary to determine these line-areas. | |||
| </p> | |||
| <p> | |||
| The line-area data includes the boundaries within the | |||
| galley of each line-area, the boundaries of each column | |||
| and the boundaries of the "page", or main area. When a | |||
| line-area boundary occurs at a hyphenation point, a | |||
| "virtual hyphen" is assumed and accounted for in the | |||
| i-p-d. As mentioned, individual footnote galleys will | |||
| hang from the parent galley. The associated data of the | |||
| footnote galleys is similar: a once-only break-points map, | |||
| and one or more line-area maps. No column boundaries are | |||
| required, but a page boundary is required at the end of | |||
| the last footnote or where a footnote breaks across a page | |||
| boundary. | |||
| </p> | |||
| <p> | |||
| A number of b-p-d values are also maintained. For each | |||
| line-area, the b-p-d, the main area b-p-d increment, the | |||
| footnote b-p-d increment and the footnote's page-related | |||
| b-p-d increment are required. The main-area b-p-d | |||
| increments for any particular line-area are dependent on | |||
| the column position of the line-area. Total b-p-d's are | |||
| also kept: total footnote b-p-d, total main area b-p-d, | |||
| and totals for each column.<br/><br/> | |||
| <strong>Figure 1</strong> Columns before first footnote. | |||
| </p> | |||
| <figure src="initial-column-values.png" alt="Columns before | |||
| first footnote"/> | |||
| </s2> | |||
| <s2 title="Balancing columns"> | |||
| <p> | |||
| <strong>Figure 2</strong> Adding a line area with first | |||
| footnote. | |||
| </p> | |||
| <figure src="line-area-5.png" | |||
| alt="Columns after adding first footnote"/> | |||
| <p> | |||
| Columns are balanced dynamically in the galley preliminary | |||
| layout. While the galley retains its basic linear | |||
| structure, the accompanying data structures accomplish | |||
| column distribution and balancing. As each line-area is | |||
| added, the columns are re-balanced. <strong>N.B.</strong> | |||
| This re-balancing involves only some of the dynamic data | |||
| associated with the participating galley(s). The data | |||
| structures associating breakpoints with the beginning and | |||
| end of individual line areas does not change in | |||
| re-balancing; only the association of line-area with column, | |||
| and, possibly, the various impact values for each line-area. | |||
| <br/><br/> | |||
| <strong>Figure 3</strong> Adding a line area with next | |||
| footnote. | |||
| </p> | |||
| <figure src="line-area-6.png" | |||
| alt="Columns after adding next footnote"/> | |||
| </s2> | |||
| <s2 title="Layout managers in the flow of control"> | |||
| <note>To be developed.</note> | |||
| </s2> | |||
| </s1> | |||
| </body> | |||
| </document> | |||
BIN
docs/design/alt.design/galley-preprocessing.png
View File
+ 0
- 210
docs/design/alt.design/galleys.xml
View File
| @@ -1,210 +0,0 @@ | |||
| <?xml version="1.0" encoding="ISO-8859-1"?> | |||
| <!-- $Id$ --> | |||
| <!-- | |||
| <!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd"> | |||
| --> | |||
| <document> | |||
| <header> | |||
| <title>Galleys</title> | |||
| <authors> | |||
| <person name="Peter B. West" email="pbwest@powerup.com.au"/> | |||
| </authors> | |||
| </header> | |||
| <body> | |||
| <!-- one of (anchor s1) --> | |||
| <s1 title="Layout galleys in FOP"> | |||
| <s2 title="Galleys in Lout"> | |||
| <p> | |||
| Jeffrey H. Kingston, in <link href = | |||
| "http://snark.niif.spb.su/~uwe/lout/design.pdf" ><em>The | |||
| Design and Implementation of the Lout Document Formatting | |||
| Language</em> Section 5</link>, describes the | |||
| <strong>galley</strong> abstraction which he implemented in | |||
| <em>Lout</em>. A document to be formatted is a stream of | |||
| text and symbols, some of which are <strong>receptive | |||
| symbols</strong>. The output file is the first receptive | |||
| symbol; the formatting document is the first galley. The | |||
| archetypical example of a receptive symbol is | |||
| <strong>@FootPlace</strong> and its corresponding galley | |||
| definition, <strong>@FootNote</strong>. | |||
| </p> | |||
| <p> | |||
| Each galley should be thought of as a concurrent process, and | |||
| each is associated with a semaphore (or synchronisation | |||
| object.) Galleys are free to "promote" components into | |||
| receptive targets as long as</p> | |||
| <ul> | |||
| <li> | |||
| an appropriate target has been encountered in the file, | |||
| </li> | |||
| <li> | |||
| the component being promoted contains no unresolved galley | |||
| targets itself, and | |||
| </li> | |||
| <li> | |||
| there is sufficient room for the galley component at the | |||
| target. | |||
| </li> | |||
| </ul> | |||
| <p> | |||
| If these conditions are not met, the galley blocks on its | |||
| semaphore. When conditions change so that further progress | |||
| may be possible, the semaphore is signalled. Note that the | |||
| galleys are a hierarchy, and that the processing and | |||
| promotion of galley contents happens <em>bottom-up</em>. | |||
| </p> | |||
| </s2> | |||
| <s2 title="Some features of galleys"> | |||
| <p> | |||
| It is essential to note that galleys are self-managing; they | |||
| are effectively layout <em>bots</em> which require only a | |||
| receptive area. If a galley fills a receptive area (say, at | |||
| the completion of a page), the galley will wait on its | |||
| semaphore, and will remain stalled until a new receptive | |||
| area is uncovered in the continued processing (say, as the | |||
| filled page is flushed to output and a new empty page is | |||
| generated.) | |||
| </p> | |||
| <p> | |||
| Difficulties with this approach become evident when there | |||
| are mutual dependencies between receptive areas which | |||
| require negotiation between the respective galleys, and, in | |||
| some cases, arbitrary deadlock breaking when there is no | |||
| clear-cut resolution to conflicting demands. Footnote | |||
| processing and side floats are examples. A thornier example | |||
| is table column layout in <em>auto</em> mode, where the | |||
| column widths are determined by the contents. In | |||
| implementing galleys in FOP, these difficulties must be | |||
| taken into account, and some solutions proposed. | |||
| </p> | |||
| <p> | |||
| Galleys model the whole of the process of creating the final | |||
| formatted output; the document as a whole is regarded as a | |||
| galley which flushes in to the output file. | |||
| </p> | |||
| </s2> | |||
| <s2 title="The layout tree"> | |||
| <anchor id="layout-tree"/> | |||
| <p> | |||
| This proposal for implementing galleys in FOP makes use of a | |||
| <strong>layout tree</strong>. As with the <link href= | |||
| "../layout.html" >layout managers</link><em></em> already | |||
| proposed, the layout tree acts as a bridge between the <link | |||
| href= "../fotree.html" >FO Tree</link> and the <link href= | |||
| "../areatree.html" >Area Tree</link>. If the elements of | |||
| the FO Tree are FO nodes, and the elements of the Area Tree | |||
| are Area nodes, representing areas to be drawn on the output | |||
| medium, the elements of the layout tree are <strong>galley | |||
| nodes</strong> and <strong>area tree fragments</strong>. | |||
| The area tree fragments are the final stages of the | |||
| resolution of the galleys; the output of the galleys will be | |||
| inserted directly into the Area Tree. The tree structure | |||
| makes it clear that the whole of the formatting process in | |||
| FOP, under this model, is a hierarchical series of galleys. | |||
| The dynamic data comes from fo:flow and fo:static-content, | |||
| and the higher-level receptive areas are derived from the | |||
| <em>layout-master-set</em>. | |||
| </p> | |||
| </s2> | |||
| <s2 title="Processing galleys"> | |||
| <p> | |||
| Galleys are processed in two basic processing environments: | |||
| </p> | |||
| <s3 title="Inline- and block-progression dimensions known"> | |||
| <p> | |||
| The galley at set-up is provided with both an | |||
| <em>inline-progression-dimension</em> (<em>i-p-d</em>) and | |||
| a <em>block-progression-dimension</em> (<em>b-p-d</em>). | |||
| In this case, no further intervention is necessary to lay | |||
| out the galley. The galley has the possibility of laying | |||
| itself out, creating all necessary area nodes. This does | |||
| not preclude the possibility that some children of this | |||
| galley will not be able to be so directly laid out, and | |||
| will fall into the second category. | |||
| </p> | |||
| <p> | |||
| While the option of "automatic" layout exists, to use | |||
| such a method would relinquish the possibility of | |||
| monitoring the results of such layout and performing | |||
| fine-tuning. | |||
| </p> | |||
| </s3> | |||
| <s3 title="Inline- ior block-progression-dimensions unknown"> | |||
| <p> | |||
| The galley cannot immediately be provided with an i-p-d | |||
| ior a b-p-d. This will occur in some of the difficult | |||
| cases mentioned earlier. In these cases, the parent | |||
| galley acts as a layout manager, similar to the sense used | |||
| in <link href= "../layout.html" >another | |||
| discussion</link>. The children, lacking full receptive | |||
| area dimensions, will proceed with galley pre-processing, | |||
| a procedure which will, of necessity, be followed | |||
| recursively by all of its children down to the atomic | |||
| elements of the galley. These atomic elements are the | |||
| individual <em>fo:character</em> nodes and images of fixed | |||
| dimensions. | |||
| </p> | |||
| </s3> | |||
| </s2> | |||
| <s2 title="Galley pre-processing"> | |||
| <anchor id="pre-processing"/> | |||
| <p> | |||
| Galley pre-processing involves the spatial resolution of | |||
| objects from the flows to the greatest extent possible | |||
| without information on the dimensions of the target area. | |||
| Line-areas have a block progression dimension which is | |||
| determined by their contents. To achieve full generality in | |||
| layouts of indeterminate dimensions, the contents of | |||
| line-areas should be laid out as though their inline | |||
| progression dimension were limited only by their content. | |||
| In terms of inline-areas, galleys would process text and | |||
| resolve the dimensions of included images. Text would be | |||
| collected into runs with the same alignment | |||
| characteristics. In the process, all possible "natural" and | |||
| hyphenation break-points can be determined. Where a | |||
| line-area contains mixed fonts or embedded images, the b-p-d | |||
| of the individual line-areas which are eventually stacked | |||
| will, in general, depend on the line break points, but the | |||
| advantage of this approach is that such actual selections | |||
| can be backed out and new break points selected with a | |||
| minimum of re-calculation. This can potentially occur | |||
| whenever a first attempt at page layout is backed out. | |||
| <br/><br/> | |||
| <strong>Figure 1</strong> | |||
| </p> | |||
| <figure src="galley-preprocessing.png" alt="Galley | |||
| pre-processing diagram"/> | |||
| <p> | |||
| Once this pre-processing has been achieved, it is | |||
| envisaged that a layout manager might make requests to the | |||
| galley of its ability to fill an area of a given | |||
| inline-progression-dimension. A positive response would | |||
| be accompanied by the block-progression-dimension. The | |||
| other possibilities are a partial fill, which would also | |||
| require b-p-d data, and a failure due to insufficient | |||
| i-p-d, in which case the minimum i-p-d requirement would | |||
| be returned. Note that decisions about the | |||
| actual dimensions of line-areas to be filled can be | |||
| deferred until all options have been tested. | |||
| </p> | |||
| <p> | |||
| The other primary form of information provided by a | |||
| pre-processed galley is its minimum and maximum i-p-d, so | |||
| that decisions can be made by the parent on the spacing of | |||
| table columns. Apart from information requests, | |||
| higher-level processes can either make requests of the | |||
| galleys for chunks of nominated sizes, or simply provide the | |||
| galley with an i-p-d and b-p-d, which will trigger the | |||
| flushing of the galley components into Area nodes. Until | |||
| they have flushed, the galleys must be able to respond to a | |||
| sequence of information requests, more or less in the manner | |||
| of a request iterator, and separately manage the flushing of | |||
| objects into the area tree. The purpose of the "request | |||
| iterator" would be to support "incremental" information | |||
| requests like <em>getNextBreakPosition</em>. | |||
| </p> | |||
| </s2> | |||
| </s1> | |||
| </body> | |||
| </document> | |||
BIN
docs/design/alt.design/initial-column-values.png
View File
+ 0
- 86
docs/design/alt.design/intro.xml
View File
| @@ -1,86 +0,0 @@ | |||
| <?xml version="1.0" standalone="no"?> | |||
| <!-- | |||
| <!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd"> | |||
| --> | |||
| <!-- $Id$ --> | |||
| <document> | |||
| <header> | |||
| <title>FOP Alternative Design</title> | |||
| <subtitle>Alternative Design Approach to FOP</subtitle> | |||
| <version>$Revision$ $Name$</version> | |||
| <authors> | |||
| <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. | |||
| </p> | |||
| <p> | |||
| 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> | |||
| </ul> | |||
| <p> | |||
| 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> | |||
| </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> | |||
| </s2> | |||
| </s1> | |||
| </body> | |||
| </document> | |||
+ 0
- 109
docs/design/alt.design/keeps.xml
View File
| @@ -1,109 +0,0 @@ | |||
| <?xml version="1.0" encoding="ISO-8859-1"?> | |||
| <!-- $Id$ --> | |||
| <!-- | |||
| <!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd"> | |||
| --> | |||
| <document> | |||
| <header> | |||
| <title>Keeps and breaks</title> | |||
| <authors> | |||
| <person name="Peter B. West" email="pbwest@powerup.com.au"/> | |||
| </authors> | |||
| </header> | |||
| <body> | |||
| <!-- 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. | |||
| </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> | |||
| </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> | |||
| </s2> | |||
| </s1> | |||
| </body> | |||
| </document> | |||
BIN
docs/design/alt.design/line-area-5.png
View File
BIN
docs/design/alt.design/line-area-6.png
View File
BIN
docs/design/alt.design/parserPersistence.png
View File
BIN
docs/design/alt.design/processPlumbing.png
View File
+ 0
- 140
docs/design/alt.design/properties-classes.xml
View File
| @@ -1,140 +0,0 @@ | |||
| <?xml version="1.0" encoding="ISO-8859-1"?> | |||
| <!-- $Id$ --> | |||
| <!-- | |||
| <!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd"> | |||
| --> | |||
| <document> | |||
| <header> | |||
| <title>Properties$classes</title> | |||
| <authors> | |||
| <person name="Peter B. West" email="pbwest@powerup.com.au"/> | |||
| </authors> | |||
| </header> | |||
| <body> | |||
| <!-- one of (anchor s1) --> | |||
| <s1 title="fo.Properties and the nested properties classes"> | |||
| <figure src="PropertyClasses.png" alt="Nested property and | |||
| 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/> | |||
| <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 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> | |||
| </s2> | |||
| <p> | |||
| <strong>Previous:</strong> <link href= "classes-overview.html" | |||
| >property classes overview.</link> | |||
| </p> | |||
| </s1> | |||
| </body> | |||
| </document> | |||
BIN
docs/design/alt.design/property-super-classes-full.png
View File
+ 0
- 341
docs/design/alt.design/propertyExpressions.xml
View File
| @@ -1,341 +0,0 @@ | |||
| <?xml version="1.0" encoding="ISO-8859-1"?> | |||
| <!-- $Id$ --> | |||
| <!-- | |||
| <!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd"> | |||
| --> | |||
| <document> | |||
| <header> | |||
| <title>Property Expression Parsing</title> | |||
| <authors> | |||
| <person id="pbw" name="Peter B. West" email="pbwest@powerup.com.au"/> | |||
| </authors> | |||
| </header> | |||
| <body> | |||
| <!-- 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. | |||
| </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. | |||
| </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>. | |||
| </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> | |||
| </s2> | |||
| <s2 title="Tokenizer"> | |||
| <p> | |||
| The tokenizer returns one of the following token | |||
| values: | |||
| </p> | |||
| <source> | |||
| static final int | |||
| EOF = 0 | |||
| ,NCNAME = 1 | |||
| ,MULTIPLY = 2 | |||
| ,LPAR = 3 | |||
| ,RPAR = 4 | |||
| ,LITERAL = 5 | |||
| ,FUNCTION_LPAR = 6 | |||
| ,PLUS = 7 | |||
| ,MINUS = 8 | |||
| ,MOD = 9 | |||
| ,DIV = 10 | |||
| ,COMMA = 11 | |||
| ,PERCENT = 12 | |||
| ,COLORSPEC = 13 | |||
| ,FLOAT = 14 | |||
| ,INTEGER = 15 | |||
| ,ABSOLUTE_LENGTH = 16 | |||
| ,RELATIVE_LENGTH = 17 | |||
| ,TIME = 18 | |||
| ,FREQ = 19 | |||
| ,ANGLE = 20 | |||
| ,INHERIT = 21 | |||
| ,AUTO = 22 | |||
| ,NONE = 23 | |||
| ,BOOL = 24 | |||
| ,URI = 25 | |||
| ,MIMETYPE = 26 | |||
| // NO_UNIT is a transient token for internal use only. It is | |||
| // 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> | |||
| </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> | |||
| </s2> | |||
| </s1> | |||
| </body> | |||
| </document> | |||
+ 0
- 177
docs/design/alt.design/spaces.xml
View File
| @@ -1,177 +0,0 @@ | |||
| <?xml version="1.0" encoding="ISO-8859-1"?> | |||
| <!-- $Id$ --> | |||
| <!-- | |||
| <!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd"> | |||
| --> | |||
| <document> | |||
| <header> | |||
| <title>Keeps and space-specifiers</title> | |||
| <authors> | |||
| <person name="Peter B. West" email="pbwest@powerup.com.au"/> | |||
| </authors> | |||
| </header> | |||
| <body> | |||
| <!-- 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. | |||
| </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> | |||
| </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"/> | |||
| </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> | |||
| </s2> | |||
| </s1> | |||
| </body> | |||
| </document> | |||
+ 0
- 369
docs/design/alt.design/traits.xml
View File
| @@ -1,369 +0,0 @@ | |||
| <?xml version="1.0" encoding="ISO-8859-1"?> | |||
| <!-- $Id$ --> | |||
| <!-- | |||
| <!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd"> | |||
| --> | |||
| <document> | |||
| <header> | |||
| <title>Traits</title> | |||
| <authors> | |||
| <person name="Peter B. West" email="pbwest@powerup.com.au"/> | |||
| </authors> | |||
| </header> | |||
| <body> | |||
| <s1 title="Traits"> | |||
| <table> | |||
| <tr> | |||
| <th>Trait</th> | |||
| <th>Applies to</th> | |||
| <th>Refs</th> | |||
| <th>Derived from</th> | |||
| </tr> | |||
| <tr> | |||
| <th>Common Traits</th> | |||
| </tr> | |||
| <tr> | |||
| <td>block-progression-direction</td> | |||
| <td>All areas</td> | |||
| <td> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice4.html#area-common" | |||
| >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> | |||
| </td> | |||
| <td> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice7.html#reference-orientation" | |||
| >7.27.7 reference-orientation</link> | |||
| </td> | |||
| </tr> | |||
| <tr> | |||
| <td>inline-progression-direction</td> | |||
| <td>All areas</td> | |||
| <td> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice4.html#area-common" | |||
| >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> | |||
| </td> | |||
| <td> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice7.html#reference-orientation" | |||
| >7.27.7 reference-orientation</link> | |||
| </td> | |||
| </tr> | |||
| <tr> | |||
| <td>shift-direction</td> | |||
| <td>Inline areas</td> | |||
| </tr> | |||
| <tr> | |||
| <td>glyph-orientation</td> | |||
| <td>Glyph-areas</td> | |||
| <td> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice4.html#area-common" | |||
| >4.2.2 Common Traits</link><br/> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice4.html#area-glyph" | |||
| >4.6.2 Glyph-areas</link><br/> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice4.html#area-linebuild" | |||
| >4.7.2 Line-building</link><br/> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice4.html#rend-intrinsic" | |||
| >4.9.5 Intrinsic Marks</link><br/> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice7.html#font-model" | |||
| >7.8.1 Fonts and Font Data</link><br/> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice7.html#writing-mode-related" | |||
| >7.27 Writing-mode-related Properties</link> | |||
| </td> | |||
| <td> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice7.html#glyph-orientation-horizontal" | |||
| >7.27.2 glyph-orientation-horizontal</link><br/> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice7.html#glyph-orientation-vertical" | |||
| >7.27.3 glyph-orientation-vertical</link><br/> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice7.html#direction" | |||
| >7.27.1 direction</link><br/> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice7.html#writing-mode" | |||
| >7.27.7 writing-mode</link> | |||
| </td> | |||
| </tr> | |||
| <tr> | |||
| <td>is-reference-area</td> | |||
| <td>All areas</td> | |||
| <td> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice5.html#section-N6691-Non-property-Based-Trait-Generation" | |||
| >5.6 Non-property Based Trait Generation</link> | |||
| </td> | |||
| <td> | |||
| Set "true" on:<br/> | |||
| simple-page-master<br/> | |||
| title<br/> | |||
| region-body<br/> | |||
| region-before<br/> | |||
| region-after<br/> | |||
| region-start<br/> | |||
| region-end<br/> | |||
| block-container<br/> | |||
| inline-container<br/> | |||
| table<br/> | |||
| table-caption<br/> | |||
| table-cell | |||
| </td> | |||
| </tr> | |||
| <tr> | |||
| <td>is-viewport-area</td> | |||
| <td></td> | |||
| <td> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice4.html#area-common" | |||
| >4.2.2 Common Traits</link> | |||
| </td> | |||
| </tr> | |||
| <tr> | |||
| <td>top-position</td> | |||
| </tr> | |||
| <tr> | |||
| <td>bottom-position</td> | |||
| </tr> | |||
| <tr> | |||
| <td>left-position</td> | |||
| </tr> | |||
| <tr> | |||
| <td>right-position</td> | |||
| </tr> | |||
| <tr> | |||
| <td>left-offset</td> | |||
| </tr> | |||
| <tr> | |||
| <td>top-offset</td> | |||
| </tr> | |||
| <tr> | |||
| <td>is-first</td> | |||
| </tr> | |||
| <tr> | |||
| <td>is-last</td> | |||
| </tr> | |||
| <tr> | |||
| <td>generated-by</td> | |||
| </tr> | |||
| <tr> | |||
| <td>returned-by</td> | |||
| </tr> | |||
| <tr> | |||
| <td>nominal-font</td> | |||
| </tr> | |||
| <tr> | |||
| <td>blink</td> | |||
| <td></td> | |||
| <td> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice5.html#refine-text-decoration" | |||
| >5.5.6 Text-decoration Property | |||
| </link> | |||
| </td> | |||
| <td> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice7.html#text-decoration" | |||
| >7.16.4 "text-decoration" | |||
| </link> | |||
| </td> | |||
| </tr> | |||
| <tr> | |||
| <td>underline-score</td> | |||
| <td></td> | |||
| <td> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice5.html#refine-text-decoration" | |||
| >5.5.6 Text-decoration Property | |||
| </link> | |||
| </td> | |||
| <td> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice7.html#text-decoration" | |||
| >7.16.4 "text-decoration" | |||
| </link> | |||
| </td> | |||
| </tr> | |||
| <tr> | |||
| <td>underline-score-color</td> | |||
| <td></td> | |||
| <td> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice5.html#refine-text-decoration" | |||
| >5.5.6 Text-decoration Property | |||
| </link> | |||
| </td> | |||
| <td> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice7.html#text-decoration" | |||
| >7.16.4 "text-decoration" | |||
| </link> | |||
| </td> | |||
| </tr> | |||
| <tr> | |||
| <td>overline-score</td> | |||
| <td></td> | |||
| <td> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice5.html#refine-text-decoration" | |||
| >5.5.6 Text-decoration Property | |||
| </link> | |||
| </td> | |||
| <td> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice7.html#text-decoration" | |||
| >7.16.4 "text-decoration" | |||
| </link> | |||
| </td> | |||
| </tr> | |||
| <tr> | |||
| <td>overline-score-color</td> | |||
| <td></td> | |||
| <td> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice5.html#refine-text-decoration" | |||
| >5.5.6 Text-decoration Property | |||
| </link> | |||
| </td> | |||
| <td> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice7.html#text-decoration" | |||
| >7.16.4 "text-decoration" | |||
| </link> | |||
| </td> | |||
| </tr> | |||
| <tr> | |||
| <td>through-score</td> | |||
| <td></td> | |||
| <td> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice5.html#refine-text-decoration" | |||
| >5.5.6 Text-decoration Property | |||
| </link> | |||
| </td> | |||
| <td> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice7.html#text-decoration" | |||
| >7.16.4 "text-decoration" | |||
| </link> | |||
| </td> | |||
| </tr> | |||
| <tr> | |||
| <td>through-score-color</td> | |||
| <td></td> | |||
| <td> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice5.html#refine-text-decoration" | |||
| >5.5.6 Text-decoration Property | |||
| </link> | |||
| </td> | |||
| <td> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice7.html#text-decoration" | |||
| >7.16.4 "text-decoration" | |||
| </link> | |||
| </td> | |||
| </tr> | |||
| <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> | |||
| <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> | |||
| <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> | |||
| <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> | |||
| <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> | |||
| <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> | |||
| <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> | |||
| <link href= | |||
| "http://www.w3.org/TR/xsl/slice4.html#area-intro" | |||
| >4.1 Introduction</link> | |||
| </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> | |||
| </table> | |||
| </s1> | |||
| </body> | |||
| </document> | |||
+ 0
- 806
docs/design/alt.design/user-agent-refs.xml
View File
| @@ -1,806 +0,0 @@ | |||
| <?xml version="1.0" encoding="ISO-8859-1"?> | |||
| <!-- $Id$ --> | |||
| <!-- | |||
| <!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd"> | |||
| --> | |||
| <document> | |||
| <header> | |||
| <title>User agent refs</title> | |||
| <authors> | |||
| <person name="Peter B. West" email="pbwest@powerup.com.au"/> | |||
| </authors> | |||
| </header> | |||
| <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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| 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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </s2> | |||
| <s2 title='7.8.2 "font-family"'> | |||
| <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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </s2> | |||
| <s2 title='7.15.11 "text-indent"'> | |||
| <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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </s2> | |||
| <s2 title='7.17.1 "color"'> | |||
| <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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </s2> | |||
| <s2 title='7.29.19 "pause"'> | |||
| <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> | |||
| </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> | |||
| </s2> | |||
| </s1> | |||
| </body> | |||
| </document> | |||
+ 0
- 224
docs/design/alt.design/xml-parsing.xml
View File
| @@ -1,224 +0,0 @@ | |||
| <?xml version="1.0" encoding="ISO-8859-1"?> | |||
| <!-- $Id$ --> | |||
| <!-- | |||
| <!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd"> | |||
| --> | |||
| <document> | |||
| <header> | |||
| <title>Integrating XML Parsing</title> | |||
| <authors> | |||
| <person name="Peter B. West" email="pbwest@powerup.com.au"/> | |||
| </authors> | |||
| </header> | |||
| <body> | |||
| <!-- 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. | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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> | |||
| </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"/> | |||
| </s2> | |||
| </s1> | |||
| </body> | |||
| </document> | |||
BIN
docs/design/alt.design/xmlevent-queue.png
View File
+ 0
- 48
docs/design/float.svg
View File
| @@ -1,48 +0,0 @@ | |||
| <?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"> | |||
| <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> | |||
| </svg> | |||
+ 0
- 50
docs/design/page.svg
View File
| @@ -1,50 +0,0 @@ | |||
| <?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"> | |||
| <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> | |||
| </svg> | |||
+ 0
- 117
docs/design/understanding/area_tree.xml
View File
| @@ -1,117 +0,0 @@ | |||
| <?xml version="1.0" standalone="no"?> | |||
| <!-- Overview --> | |||
| <document> | |||
| <header> | |||
| <title>Area Tree</title> | |||
| <subtitle>All you wanted to know about the Area Tree !</subtitle> | |||
| <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> | |||
| </authors> | |||
| </header> | |||
| <body><s1 title="Area Tree"> | |||
| <s2 title="Area Tree"> | |||
| <p>The Area Tree is an internal representation of the result document. This | |||
| is a set of java classes that can put together a set of objects that | |||
| represent the pages and their contents.</p> | |||
| <p>This information is created by the layout managers and is rendered to the | |||
| output using a renderer.</p> | |||
| <p>The Area Tree follows the description of the area tree in the XSL:FO | |||
| specification.</p> | |||
| <p>The Area Tree consists of a set of pages, the actual implemenation places | |||
| these in | |||
| a set of page sequences.</p></s2> | |||
| <s2 title="Pages"> | |||
| <p>A page consists of a page+viewport pair.</p> | |||
| <p>The PageViewPort and Page with the regions is created by the | |||
| LayoutMasterSet. The contents are then placed by the layout managers. Once | |||
| the layout of a page is complete then it is added to the Area Tree.</p> | |||
| <p>Inside the page is a set of RegionViewport+Region pairs for each region on | |||
| the page.</p></s2> | |||
| <s2 title="Blocks"> | |||
| <p>Block level areas contain either other blocks or line areas (which is a | |||
| special block area).</p><p> | |||
| A block is either positoned or stacked with other block areas.</p> | |||
| </s2> | |||
| <s2 title="Inline Areas"> | |||
| <p>Inline areas are stacked in a line area. Inline areas are objects such as | |||
| character, viewport, inline-container, leader and space. A special inline | |||
| area Word is also used for a group of consecutive characters.</p> | |||
| <p>The image and instream foreign object areas are placed inside a viewport. | |||
| The leader (with use content) and unresolved page number areas are | |||
| resolved to other inline areas.</p> | |||
| <p>Once a LineArea is filled with inline areas then the inline areas need to | |||
| be aligned and adjusted to fill the line properly.</p></s2> | |||
| <s2 title="Traits"> | |||
| <p>A trait is information associated with an area. This could be information | |||
| such as text colour or is-first.</p> | |||
| <p>Traits provide information about an area. The traits are derived from | |||
| properties on the formatting object or are generated during the layout | |||
| process. Many of the layout traits do not have actual values but can be | |||
| derived from the Area Tree. Other traits that apply when rendering the | |||
| areas are set on the area. Since setting the same value on every area | |||
| would use a lot of memory then the traits are derived from default or | |||
| parent values.</p> | |||
| <p>A dominant trait on a block area is set, for example font colour, so that | |||
| every line area with the same dominant value can derive it. The text | |||
| inline areas then get the font colour set on the inline area or from the | |||
| line area or from the block area.</p></s2> | |||
| <s2 title="Forward References"> | |||
| <p>The Area Tree maintains a set of mappings from the reference to pages.</p> | |||
| <p>The PageViewPort holds the list of forward references that need resolving | |||
| so that if a references is resolved during layout the page can be easily | |||
| found and then fixed. Once all the forward references are resolved then | |||
| the page is ready to be rendered.</p> | |||
| <p>To layout a page any areas that cannot be resolved need to reserve space. | |||
| Once the inline area is resolved then the complete line should be adjusted | |||
| to accomodate any change in space used by the area.</p></s2> | |||
| <s2 title="Caching"> | |||
| <p>We may need to cache pages due to forward references or when keeping all | |||
| pages.</p> | |||
| <p>This is done by serializing the Page. The PageViewport is retained to be | |||
| used as a key for page references and backward references. | |||
| The Page is serialized to an object stream and then all of the page | |||
| contents are released. The Page is then recoved by reading from the object | |||
| stream.</p> | |||
| <p>The PageViewport retains information about id areas for easy access.</p> | |||
| </s2> | |||
| <s2 title="Extensions"> | |||
| <p>The Area Tree holds the Output Document extensions. This is information | |||
| such as pdf bookmarks or other output document specific information that | |||
| is not handled by XSL:FO.</p> | |||
| <p>It is also possible to create custom areas that extend a normal area. The | |||
| actual data that is rendered could be set in a different way or depend on | |||
| resolving a forward reference.</p> | |||
| </s2> | |||
| <s2 title="Area Tree Handlers"> | |||
| <p>To handle different situations the handler for the Area Tree handles each | |||
| page as it is added.</p><p> | |||
| The RenderPagesModel sends the page directly to the renderer if the page | |||
| is ready to be rendered. Once a page is rendered it is discarded. | |||
| The StorePagesModel stores all the pages so that any page can be later | |||
| accessed.</p> | |||
| <p>The Area Tree retains the concept of page sequences (this is not in the | |||
| area tree in the spec) so that this information can be passed to the | |||
| renderer. This is useful for setting the title and organising the groups | |||
| of page sequences.</p></s2> | |||
| <s2 title="Associated Tasks"> | |||
| <ul><li>Sort out extensions concept, access to AreaTree.</li> | |||
| <li>Sort out trait handling.</li> | |||
| <li>Caching implementation.</li></ul></s2> | |||
| </s1> | |||
| </body></document> | |||
+ 0
- 23
docs/design/understanding/book.xml
View File
| @@ -1,23 +0,0 @@ | |||
| <?xml version="1.0"?> | |||
| <book title="FOP Design" copyright="1999-2002 The Apache Software Foundation"> | |||
| <external href="http://xml.apache.org/fop/" label="About FOP"/> | |||
| <separator/> | |||
| <external href="../index.html" label="NEW DESIGN" /> | |||
| <page id="index" label="Uderstanding" source="understanding.xml"/> | |||
| <separator/> | |||
| <page id="xml_parsing" label="XML Parsing" source="xml_parsing.xml"/> | |||
| <page id="fo_tree" label="FO Tree" source="fo_tree.xml"/> | |||
| <page id="properties" label="Properties" source="properties.xml"/> | |||
| <page id="layout_managers" label="Layout Managers" source="layout_managers.xml"/> | |||
| <page id="layout_process" label="Layout Process" source="layout_process.xml"/> | |||
| <page id="handling_attributes" label="Handling Attributes" source="handling_attributes.xml"/> | |||
| <page id="area_tree" label="Area Tree" source="area_tree.xml"/> | |||
| <page id="renderers" label="Renderers" source="renderers.xml"/> | |||
| <separator/> | |||
| <page id="images" label="Images" source="images.xml"/> | |||
| <page id="pdf_library" label="PDF Library" source="pdf_library.xml"/> | |||
| <page id="svg" label="SVG" source="svg.xml"/> | |||
| <separator/> | |||
| <page id="status" label="Status" source="status.xml"/> | |||
| </book> | |||
+ 0
- 184
docs/design/understanding/fo_tree.xml
View File
| @@ -1,184 +0,0 @@ | |||
| <?xml version="1.0"?> | |||
| <document> | |||
| <header> | |||
| <title>FO Tree</title> | |||
| <subtitle>All you wanted to know about FO Tree !</subtitle> | |||
| <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> | |||
| </authors> | |||
| </header> | |||
| <body><s1 title="FO Tree"> | |||
| <p> | |||
| The FO Tree is a representation of the XSL:FO document. This | |||
| represents the <strong>Objectify</strong> step from the | |||
| spec. The <strong>Refinement</strong> step is part of reading | |||
| and using the properties which may happen immediately or | |||
| during the layout process. | |||
| </p> | |||
| <p>Each xml element is represented by a java object. For pagination the | |||
| classes are in <code>org.apache.fop.fo.pagination.*</code>, for elements in the flow | |||
| they are in <code>org.apache.fop.fo.flow.*</code> and some others are in | |||
| <code>org.apache.fop.fo.*.</code></p> | |||
| <p>The base class for all objects in the tree is FONode. The base class for | |||
| all FO Objects is FObj.</p> | |||
| <p>(insert diagram here)</p> | |||
| <p>There is a class for each element in the FO set. An object is created for | |||
| each element in the FO Tree. This object holds the properties for the FO | |||
| Object.</p> | |||
| <p> | |||
| When the object is created it is setup. It is given its | |||
| element name, the FOUserAgent - for resolving properties | |||
| etc. - the logger and the attributes. The methods | |||
| <code>handleAttributes()</code> and | |||
| <code>setuserAgent()</code>, common to <code>FONode</code>, | |||
| are used in this process. The object will then be given any | |||
| text data or child elements. Then the <code>end()</code> | |||
| method is called. The end method is used by a number of | |||
| elements to indicate that it can do certain processing since | |||
| all the children have been added. | |||
| </p> | |||
| <p>Some validity checking is done during these steps. The user can be warned of the error and processing can continue if possible. | |||
| </p> | |||
| <p> | |||
| The FO Tree is simply a heirarchy of java objects that | |||
| represent the fo elements from xml. The traversal is done by | |||
| the layout or structure process only in the flow elements. | |||
| </p> | |||
| <s2 title="Properties"> | |||
| <p>The XML attributes on each element are passed to the object. The objects | |||
| that represent FO objects then convert the attributes into properties. | |||
| </p> | |||
| <p>Since properties can be inherited the PropertyList class handles resolving | |||
| properties for a particular element. | |||
| All properties are specified in an XML file. Classes are created | |||
| automatically during the build process. | |||
| </p> | |||
| <p>(insert diagram here)</p> | |||
| <p>In some cases the element may be moved to have a different parent, for | |||
| example markers, or the inheritance could be different, for example | |||
| initial property set.</p></s2> | |||
| <s2 title="Foreign XML"> | |||
| <p>The base class for foreign XML is XMLObj. This class handles creating a | |||
| DOM Element and the setting of attributes. It also can create a DOM | |||
| Document if it is a top level element, class XMLElement. | |||
| This class must be extended for the namespace of the XML elements. For | |||
| unknown namespaces the class is UnknowXMLObj.</p> | |||
| <p>(insert diagram here)</p> | |||
| <p>If some special processing is needed then the top level element can extend | |||
| the XMLObj. For example the SVGElement makes the special DOM required for | |||
| batik and gets the size of the svg. | |||
| </p> | |||
| <p>Foreign XML will usually be in an fo:instream-foreign-object, the XML will | |||
| be passed to the render as a DOM where the render will be able to handle | |||
| it. Other XML from an unknwon namespace will be ignored. | |||
| </p> | |||
| <p>By using element mappings it is possible to read other XML and either</p> | |||
| <ul><li>set information on the area tree</li> | |||
| <li>create pseudo FO Objects that create areas in the area tree</li> | |||
| <li>create FO Objects</li></ul> | |||
| </s2> | |||
| <s2 title="Unknown Elements"> | |||
| <p>If an element is in a known namespace but the element is unknown then an | |||
| Unknown object is created. This is mainly to provide information to the | |||
| user. | |||
| This could happen if the fo document contains an element from a different | |||
| version or the element is misspelt.</p> | |||
| </s2> | |||
| <s2 title="Page Masters"> | |||
| <p> | |||
| The first elements in a document are the elements for the | |||
| page master setup. This is usually only a small number and | |||
| will be used throughout the document to create new pages. | |||
| These elements are kept as a factory to create the page and | |||
| appropriate regions whenever a new page is requested by the | |||
| layout. The objects in the FO Tree that represent these | |||
| elements are themselves the factory. The root element keeps | |||
| these objects as a factory for the page sequences. | |||
| </p> | |||
| </s2> | |||
| <s2 title="Flow"> | |||
| <p>The elements that are in the flow of the document are a set of elements | |||
| that is needed for the layout process. Each element is important in the | |||
| creation of areas.</p> | |||
| </s2> | |||
| <s2 title="Other Elements"> | |||
| <p> | |||
| The remaining FO Objects are things like page-sequence, | |||
| title and color-profile. These are handled by their parent | |||
| element; i.e. the root looks after the declarations and the | |||
| declarations maintains a list of colour profiles. The | |||
| page-sequences are direct descendents of root. | |||
| </p> | |||
| </s2> | |||
| <s2 title="Associated Tasks"> | |||
| <ul><li>Create diagrams</li> | |||
| <li>Setup all properties and elements for XSL:FO</li> | |||
| <li>Setup user agent for property resolution</li> | |||
| <li>Verify all XML is handled appropriately</li></ul></s2></s1></body></document> | |||
+ 0
- 13
docs/design/understanding/handling_attributes.xml
View File
| @@ -1,13 +0,0 @@ | |||
| <?xml version="1.0" standalone="no"?> | |||
| <!-- Overview --> | |||
| <document> | |||
| <header> | |||
| <title>Handling Attributes</title> | |||
| <subtitle>All you wanted to know about FOP Handling Attributes !</subtitle> | |||
| <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> | |||
| </authors> | |||
| </header> | |||
| <body><s1 title="Handling Attributes"> | |||
| <p>Yet to come :))</p> | |||
| <note>The series of notes for developers has started but it has not yet gone so far ! Keep watching</note></s1> | |||
| </body></document> | |||
+ 0
- 146
docs/design/understanding/images.xml
View File
| @@ -1,146 +0,0 @@ | |||
| <?xml version="1.0" standalone="no"?> | |||
| <!-- Overview --> | |||
| <document> | |||
| <header> | |||
| <title>Images</title> | |||
| <subtitle>All you wanted to know about Images in FOP !</subtitle> | |||
| <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> | |||
| </authors> | |||
| </header> | |||
| <body> | |||
| <s1 title="Images in FOP"> <note> this is still in progress, input in the code is welcome. Needs documenting formats, testing. | |||
| So all those people interested in images should get involved.</note> | |||
| <p>Images may only be needed to be loaded when the image is rendered to the | |||
| output or to find the dimensions.<br/> | |||
| An image url may be invalid, this can be costly to find out so we need to | |||
| keep a list of invalid image urls.</p> | |||
| <p>We have a number of different caching schemes that are possible.</p> | |||
| <p>All images are referred to using the url given in the XSL:FO after | |||
| removing "url('')" wrapping. This does | |||
| not include any sort of resolving such as relative -> absolute. The | |||
| external graphic in the FO Tree and the image area in the Area Tree only | |||
| have the url as a reference. | |||
| The images are handled through a static interface in ImageFactory.<br/></p> | |||
| <p>(insert image)</p> | |||
| <s2 title="Threading"> | |||
| <p>In a single threaded case with one document the image should be released | |||
| as soon as the renderer caches it. If there are multiple documents then | |||
| the images could be held in a weak cache in case another document needs to | |||
| load the same image.</p> | |||
| <p>In a multi threaded case many threads could be attempting to get the same | |||
| image. We need to make sure an image will only be loaded once at a | |||
| particular time. Once a particular document is finished then we can move | |||
| all the images to a common weak cache.</p> | |||
| </s2> | |||
| <s2 title="Caches"> | |||
| <s3 title="LRU"> | |||
| <p>All images are in a common cache regardless of context. To limit the size | |||
| of the cache the LRU image is removed to keep the amount of memory used | |||
| low. Each image can supply the amount of data held in memory.</p> | |||
| </s3> | |||
| <s3 title="Context"> | |||
| <p>Images are cached according to the context, using the FOUserAgent as a key. | |||
| Once the context is finished the images are added to a common weak hashmap | |||
| so that other contexts can load these images or the data will be garbage | |||
| collected if required.</p> | |||
| <p>If images are to be used commonly then we cannot dispose of data in the | |||
| FopImage when cached by the renderer. Also if different contexts have | |||
| different base directories for resolving relative url's then the loading | |||
| and caching must be separate. We can have a cache that shares images among | |||
| all contexts or only loads an image for a context.</p> | |||
| </s3> | |||
| <p>The cache uses an image loader so that it can synchronize the image | |||
| loading on an image by image basis. Finding and adding an image loader to | |||
| the cache is also synchronized to prevent thread problems.</p> | |||
| </s2> | |||
| <s2 title="Invalid Images"> | |||
| <p> | |||
| If an image cannot be loaded for some reason, for example the url is | |||
| invalid or the image data is corrupt or an unknown type. Then it should | |||
| only attempt to load the image once. All other attempts to get the image | |||
| should return null so that it can be easily handled.<br/> | |||
| This will prevent any extra processing or waiting.</p> | |||
| </s2> | |||
| <s2 title="Reading"> | |||
| <p>Once a stream is opened for the image url then a set of image readers is | |||
| used to determine what type of image it is. The reader can peek at the | |||
| image header or if necessary load the image. The reader can also get the | |||
| image size at this stage. | |||
| The reader then can provide the mime type to create the image object to | |||
| load the rest of the information.<br/></p></s2> | |||
| <s2 title="Data"> | |||
| <p>The data usually need for an image is the size and either a bitmap or the | |||
| original data. Images such as jpeg and eps can be embedded into the | |||
| document with the original data. SVG images are converted into a DOM which | |||
| needs to be rendered to the PDF. Other images such as gif, tiff etc. are | |||
| converted into a bitmap. | |||
| Data is loaded by the FopImage by calling load(type) where type is the type of data to load.<br/></p></s2> | |||
| <s2 title="Rendering"> | |||
| <p>Different renderers need to have the information in different forms.</p> | |||
| <s3 title="PDF"> | |||
| <dl><dt>original data</dt> <dd>JPG, EPS</dd> | |||
| <dt>bitmap</dt> <dd>gif, tiff, bmp, png</dd> | |||
| <dt>other</dt> <dd>SVG</dd></dl> | |||
| </s3> | |||
| <s3 title="PS"> | |||
| <dl><dt>bitmap</dt> <dd>JPG, gif, tiff, bmp, png</dd> | |||
| <dt>other</dt> <dd>SVG</dd></dl> | |||
| </s3> | |||
| <s3 title="awt"> | |||
| <dl><dt>bitmap</dt> <dd>JPG, gif, tiff, bmp, png</dd> | |||
| <dt>other</dt> <dd>SVG</dd></dl></s3> | |||
| <p>The renderer uses the url to retrieve the image from the ImageFactory and | |||
| then load the required data depending on the image mime type. If the | |||
| renderer can insert the image into the document and use that data for all | |||
| future references of the same image then it can cache the reference in the | |||
| renderer and the image can be released from the image cache.</p></s2> | |||
| </s1> | |||
| </body></document> | |||
+ 0
- 67
docs/design/understanding/layout_managers.xml
View File
| @@ -1,67 +0,0 @@ | |||
| <?xml version="1.0" standalone="no"?> | |||
| <!-- Overview --> | |||
| <document> | |||
| <header> | |||
| <title>Layout Managers</title> | |||
| <subtitle>All you wanted to know about Layout Managers !</subtitle> | |||
| <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> | |||
| </authors> | |||
| </header> | |||
| <body><s1 title="Layout Managers"> | |||
| <p>The role of the layout managers is to build the Area Tree by using the | |||
| information from the FO Tree. The layout managers decide where information | |||
| is placed in the area tree.</p> | |||
| <p>A layout manager is typically associated with an FO Object but not always.</p> | |||
| <p>The layout managers are in between the FO Tree and the Area Tree. They get | |||
| information from the FO Tree and create areas and build the pages. They | |||
| hold the state of the layout process as it builds up the areas and pages. | |||
| They also manage the handling of breaks and spacing between areas.</p> | |||
| <p>FO Objects can have two types of properties, ones that relate to the layout and ones that relate to the rendering. THe layout related properties area used by the layout managers to determine how and where to create the areas. The render related properties should be passed through to the renderer in the most efficient way possible. | |||
| </p> | |||
| <s2 title="Block Areas"> | |||
| <p>When a block creating element is complete then it is possible to build the | |||
| block area and add it to the paprent.</p> | |||
| <p>A block area will contain either more block areas or line areas, which are | |||
| special block areas. The line areas are created by the LineLayoutManager | |||
| in which the inline areas flow into.</p> | |||
| <p>So a block area manager handles the lines or blocks as its children and | |||
| determines things like spacing and breaks.</p> | |||
| <p>In the case of tables and lists the blocks are stacked in a specific way | |||
| that needs to be handled by the layout manager.</p></s2> | |||
| <s2 title="Side Floats"> | |||
| <p>Side floats alter the length of the inline progression dimension for the | |||
| current line and following lines for the size of the float.</p> | |||
| <p>This means that the float needs to be handled by the block layout manager | |||
| so that it can adjust the available inline progression dimension for the | |||
| relevant line areas.</p></s2> | |||
| <s2 title="Footnotes and Before Floats"> | |||
| <p>Footnotes and Before Floats are placed in special areas in the body region | |||
| of the page. The size of these areas is determined by the content. This in | |||
| turn effects the available size of the main reference area that contains | |||
| the flow.</p> | |||
| <p>A layout manager handles the adding and removing of footnotes/floats, this in turn effects the available space in the main reference area.</p> | |||
| </s2> | |||
| <note>(note: more info to follow)</note> | |||
| </s1> | |||
| </body></document> | |||
+ 0
- 13
docs/design/understanding/layout_process.xml
View File
| @@ -1,13 +0,0 @@ | |||
| <?xml version="1.0" standalone="no"?> | |||
| <!-- Overview --> | |||
| <document> | |||
| <header> | |||
| <title>Layout Process</title> | |||
| <subtitle>All you wanted to know about the Layout Process !</subtitle> | |||
| <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> | |||
| </authors> | |||
| </header> | |||
| <body><s1 title="Layout Process"> | |||
| <p>Yet to come :))</p> | |||
| <note>The series of notes for developers has started but it has not yet gone so far ! Keep watching</note></s1> | |||
| </body></document> | |||
+ 0
- 78
docs/design/understanding/pdf_library.xml
View File
| @@ -1,78 +0,0 @@ | |||
| <?xml version="1.0" standalone="no"?> | |||
| <!-- Overview --> | |||
| <document> | |||
| <header> | |||
| <title>PDF Library</title> | |||
| <subtitle>All you wanted to know about the PDF Library !</subtitle> | |||
| <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> | |||
| </authors> | |||
| </header> | |||
| <body><s1 title="PDF Library"> | |||
| <p>The PDF Library is an independant package of classes in FOP. These class | |||
| provide a simple way to construct documents and add the contents. The | |||
| classes are found in <code>org.apache.fop.pdf.*</code>.</p> | |||
| <s2 title="PDF Document"> | |||
| <p>This is where most of the document is created and put together.</p> | |||
| <p>It sets up the header, trailer and resources. Each page is made and added to the document. | |||
| There are a number of methods that can be used to create/add certain PDF objects to the document.</p> | |||
| </s2> | |||
| <s2 title="Building PDF"> | |||
| <p>The PDF Document is built by creating a page for each page in the Area Tree.</p> | |||
| <p> This page then has all the contents added. | |||
| The page is then added to the document and available objects can be written to the output stream.</p> | |||
| <p>The contents of the page are things such as text, lines, images etc. | |||
| The PDFRenderer inserts the text directly into a pdf stream. | |||
| The text consists of markup to set fonts, set text position and add text.</p> | |||
| <p>Most of the simple pdf markup is inserted directly into a pdf stream. | |||
| Other more complex objects or commonly used objects are added through java classes. | |||
| Some pdf objects such as an image consists of two parts.</p> | |||
| <p>It has a separate object for the image data and another bit of markup to display the image in a certain position on the page. | |||
| </p><p>The java objects that represent a pdf object implement a method that returns the markup for inserting into a stream. | |||
| The method is: byte[] toPDF().</p> | |||
| </s2> | |||
| <s2 title="Features"> | |||
| <s3 title="Fonts"> | |||
| <p>Support for embedding fonts and using the default Acrobat fonts. | |||
| </p></s3> | |||
| <s3 title="Images"> | |||
| <p>Images can be inserted into a page. The image can either be inserted as a pixel map or directly insert a jpeg image. | |||
| </p></s3> | |||
| <s3 title="Stream Filters"> | |||
| <p>A number of filters are available to encode the pdf streams. These filters can compress the data or change it such as converting to hex. | |||
| </p></s3> | |||
| <s3 title="Links"> | |||
| <p>A pdf link can be added for an area on the page. This link can then point to an external destination or a position on any page in the document. | |||
| </p></s3> | |||
| <s3 title="Patterns"> | |||
| <p>The fill and stroke of graphical objects can be set with a colour, pattern or gradient. | |||
| </p></s3> | |||
| <p>The are a number of other features for handling pdf markup relevent to creating PDF files for FOP.</p> | |||
| </s2> | |||
| <s2 title="Associated Tasks"> | |||
| <p>There are a large number of additional features that can be added to pdf.</p> | |||
| <p>Many of these can be handled with extensions or post processing.</p> | |||
| </s2> | |||
| </s1> | |||
| </body></document> | |||
+ 0
- 130
docs/design/understanding/properties.xml
View File
| @@ -1,130 +0,0 @@ | |||
| <?xml version="1.0" standalone="no"?> | |||
| <!-- Overview --> | |||
| <document> | |||
| <header> | |||
| <title>Properties</title> | |||
| <subtitle>All you wanted to know about the Properties !</subtitle> | |||
| <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> | |||
| </authors> | |||
| </header> | |||
| <body><s1 title="Property Handling"> | |||
| <p>During XML Parsing, the FO tree is constructed. For each FO object (some | |||
| subclass of FObj), the tree builder then passes the list of all | |||
| attributes specified on the FO element to the handleAttrs method. This | |||
| method converts the attribute specifications into a PropertyList.</p> | |||
| <p>The actual work is done by a PropertyListBuilder (PLB for short). The | |||
| basic idea of the PLB is to handle each attribute in the list in turn, | |||
| find an appropriate "Maker" for it, call the Maker to convert the | |||
| attribute value into a Property object of the correct type, and store | |||
| that Property in the PropertyList.</p> | |||
| <s2 title="Finding a Maker"> | |||
| <p> | |||
| The PLB finds a "Maker" for the property based on the attribute name and | |||
| the element name. Most Makers are generic and handle the attribute on | |||
| any element, but it's possible to set up an element-specific property | |||
| Maker. The attribute name to Maker mappings are automatically created | |||
| during the code generation phase by processing the XML property | |||
| description files.</p> | |||
| </s2> | |||
| <s2 title="Processing the attribute list"> | |||
| <p>The PLB first looks to see if the font-size property is specified, since | |||
| it sets up relative units which can be used in other property | |||
| specifications. Each attribute is then handled in turn. If the attribute | |||
| specifies part of a compound property such as space-before.optimum, the | |||
| PLB looks to see if the attribute list also contains the "base" property | |||
| (space-before in this case) and processes that first.</p></s2> | |||
| <s2 title="How the Property Maker works"><p>There is a family of Maker objects for each of the property datatypes, | |||
| such as Length, Number, Enumerated, Space, etc. But since each Property | |||
| has specific aspects such as whether it's inherited, its default value, | |||
| its corresponding properties, etc. there is usually a specific Maker for | |||
| each Property. All these Maker classes are created during the code | |||
| generation phase by processing (using XSLT) the XML property description | |||
| files to create Java classes.</p> | |||
| <p>The Maker first checks for "keyword" values for a property. These are | |||
| things like "thin, medium, thick" for the border-width property. The | |||
| datatype is really a Length but it can be specified using these keywords | |||
| whose actual value is determined by the "User Agent" rather than being | |||
| specified in the XSL standard. For FOP, these values are currently | |||
| defined in foproperties.xml. The keyword value is just a string, so it | |||
| still needs to be parsed as described next.</p> | |||
| <p>The Maker also checks to see if the property is an Enumerated type and | |||
| then checks whether the value matches one of the specified enumeration | |||
| values.</p> | |||
| <p>Otherwise the Maker uses the property parser in the fo.expr package to | |||
| evaluate the attribute value and return a Property object. The parser | |||
| interprets the expression language and performs numeric operations and | |||
| function call evaluations.</p> | |||
| <p>If the returned Property value is of the correct type (specificed in | |||
| foproperties.xml, where else?), the Maker returns it. Otherwise, it may | |||
| be able to convert the returned type into the correct type.</p> | |||
| <p>Some kinds of property values can't be fully resolved during FO tree | |||
| building because they depend on layout information. This is the case of | |||
| length values specified as percentages and of the special | |||
| proportional-column-width(x) specification for table-column widths. | |||
| These are stored as special kinds of Length objects which are evaluated | |||
| during layout. Expressions involving "em" units which are relative to | |||
| font-size _are_ resolved during the FO tree building however.</p></s2> | |||
| <s2 title="Structure of the PropertyList"> | |||
| <p>The PropertyList extends HashMap and its basic function is to associate | |||
| Property value objects with Property names. The Property objects are all | |||
| subclasses of the base Property class. Each one simply contains a | |||
| reference to one of the property datatype objects. Property provides | |||
| accessors for all known datatypes and various subclasses override the | |||
| accessor(s) which are reasonable for the datatype they store.</p> | |||
| <p>The PropertyList itself provides various ways of looking up Property | |||
| values to handle such issues as inheritance and corresponding | |||
| properties. </p> | |||
| <p>The main logic is:<br/>If the property is a writing-mode relative property (using start, end, | |||
| before or after in its name), the corresponding absolute property value | |||
| is returned if it's explicitly set on this FO. <br/>Otherwise, the | |||
| writing-mode relative value is returned if it's explicitly set. If the | |||
| property is inherited, the process repeats using the PropertyList of the | |||
| FO's parent object. (This is easy because each PropertyList points to | |||
| the PropertyList of the nearest ancestor FO.) If the property isn't | |||
| inherited or no value is found at any level, the initial value is | |||
| returned.</p></s2> | |||
| <s2 title="References"> | |||
| <dl><dt>docs/design/properties.xml</dt> <dd>a more detailed version of this (generated | |||
| html in docs/html-docs/design/properties.html)</dd> | |||
| <dt>src/codegen/properties.dtd</dt> <dd>heavily commented DTD for foproperties.xml, | |||
| but may not be completely up-to-date</dd></dl></s2> | |||
| <s2 title="To Do"> <s3 title="documentation"> | |||
| <ul><li>explain PropertyManager vs. direct access</li> | |||
| <li>Explain corresponding properties</li></ul></s3> | |||
| <s3 title="development"> | |||
| <p>Lots of properties are incompletely handled, especially funny kinds of | |||
| keyword values and shorthand values (one attribute which sets several | |||
| properties)</p></s3></s2> | |||
| </s1> | |||
| </body></document> | |||
+ 0
- 115
docs/design/understanding/renderers.xml
View File
| @@ -1,115 +0,0 @@ | |||
| <?xml version="1.0" standalone="no"?> | |||
| <!-- Overview --> | |||
| <document> | |||
| <header> | |||
| <title>Renderers</title> | |||
| <subtitle>All you wanted to know about the Renderers !</subtitle> | |||
| <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> | |||
| </authors> | |||
| </header> | |||
| <body><s1 title="Renderers"> | |||
| <s2 title="Renderers"> | |||
| <p>A renderer is used to convert the Area Tree into the output document. | |||
| The renderer is given the tree one page at a time. All pages are supplied | |||
| in the order they appear in the document. In order to save memory it is | |||
| possble to render the pages out of order. Any page that is not reeady to | |||
| be rendered is setup by the renderer first so that it can reserve a space | |||
| or reference for when the page is ready to be rendered.</p> | |||
| <p>The AbstractRenderer does most of the work to iterate through the area | |||
| tree parts. This means that the most renderers simply need to implement | |||
| the specific parts with inserting text, images and lines. The methods can | |||
| easily be overridden to handle things in a different way or do some extra | |||
| processing.</p></s2> | |||
| <s2 title="Fonts"> | |||
| <p>The fonts are setup by the renderer being used. The font metrics are used | |||
| during the layout process to determine the size of characters.</p> | |||
| </s2> | |||
| <s2 title="Render Context"> | |||
| <p>The render context is used by handlers. It contains information about the | |||
| current state of the renderer. Such as the page, the position and any | |||
| other miscellanous objects that are required to draw into the page.</p></s2> | |||
| <s2 title="XML Handling"> | |||
| <p>A document may contain information in the form of XML for an image or | |||
| instream foreign object. This XML is handled | |||
| through the user agent. A standard extension for PDF is the SVG handler.</p><p> | |||
| If there is XML in the SVG namespace it is given to the handler which | |||
| renders the SVG into the pdf document at the given location. | |||
| This separation means that other XML handlers can easily be added.</p></s2> | |||
| <s2 title="Extensions"> | |||
| <p>Document level extensions are handled with an extension handler. This | |||
| handles the information from the AreaTree and adds renders it to the | |||
| document. An example is the pdf bookmarks. This information first needs to | |||
| have all references resolved. Then the extension handler is ready to put | |||
| the information into the pdf document.</p></s2> | |||
| <s2 title="Types"> | |||
| <s3 title="PDF"> | |||
| <p>This uses the PDFDocument classes to create a PDF document. This supports | |||
| out of order rendering as it is possible to reserve a pdf page object that | |||
| can be later filled. Most of the work is to insert text or create lines. | |||
| SVG is handled by the XML handler that uses the PDFGraphics2D and batik to | |||
| draw the svg into the pdf page.</p><p> | |||
| This also allows for font embedding.</p> | |||
| </s3> | |||
| <s3 title="SVG"> | |||
| <p>This creates a single svg document that contains all the pages rendered | |||
| with page sequences horizontally and pages vertically. This also adds | |||
| links between the pages so that it can be viewed by clicking on the page | |||
| to go to the next page.</p></s3> | |||
| <s3 title="TXT"> | |||
| <p>This simply outputs to a text document.</p></s3> | |||
| <s3 title="AWT"> | |||
| <p>This draws the pages into an AWT graphic.</p></s3> | |||
| <s3 title="PS and PCL"> | |||
| <p>Similar to PDF.</p></s3> | |||
| <s3 title="XML"> | |||
| <p>Creates an XML file that represents the AreaTree.</p> | |||
| </s3> | |||
| <s3 title="Print"> | |||
| <p>This prints the document using the java printing facitlities. The AWT | |||
| rendering is used to draw the pages onto the printjob. | |||
| </p></s3> | |||
| <s3 title="RTF and MIF"> | |||
| <p>These formats do not use this rendering mechanism.</p></s3> | |||
| </s2> | |||
| <s2 title="Adding a Renderer"> | |||
| <p>It is also possible to add other renderers. The renderer simply needs to | |||
| implement the Renderer interface. The AbstractRenderer does most of what | |||
| is needed so it is better to extend this. This means that you only need to | |||
| implement the basic functionality such as text and lines. | |||
| </p></s2> | |||
| <s2 title="Multiple Renderers"> | |||
| <p>The layout of the document depends mainly on the font being used. | |||
| If two renderers have the same font metrics then it is possible to render | |||
| the Area Tree in each renderer. This can be handled by the AreaTree | |||
| Handler.</p></s2> | |||
| <s2 title="Associated Tasks"> | |||
| <ul><li>Sort out multiple renderers concept.</li></ul> | |||
| </s2> | |||
| </s1> | |||
| </body></document> | |||
+ 0
- 17
docs/design/understanding/status.xml
View File
| @@ -1,17 +0,0 @@ | |||
| <?xml version="1.0" standalone="no"?> | |||
| <!-- Overview --> | |||
| <document> | |||
| <header> | |||
| <title>Tutorial series Status</title> | |||
| <subtitle>Current Status of tutorial about FOP and Design</subtitle> | |||
| <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> | |||
| </authors> | |||
| </header> | |||
| <body><s1 title="Tutorial series Status"> <p>Peter said : Do we have a volunteer to track | |||
| Keiron's tutorials and turn them into web page documentation?</p> <p><strong>The answer is yes | |||
| we have, but the work is on progress !</strong></p> <note>Keiron has recently extended | |||
| the documentation generation on the CVS trunk to make this process a bit | |||
| easier. Keiron tells Peter that Apache is readying a major overhaul of its web | |||
| site and xml->html generation, but that should not deter us from proceeding | |||
| with documentation.</note></s1> | |||
| </body></document> | |||
+ 0
- 57
docs/design/understanding/svg.xml
View File
| @@ -1,57 +0,0 @@ | |||
| <?xml version="1.0" standalone="no"?> | |||
| <!-- Overview --> | |||
| <document> | |||
| <header> | |||
| <title>SVG</title> | |||
| <subtitle>All you wanted to know about SVG and FOP !</subtitle> | |||
| <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> | |||
| </authors> | |||
| </header> | |||
| <body><s1 title="SVG"> | |||
| <p>SVG is rendered through Batik.</p><p>The XML from the XSL:FO document | |||
| is converted into an SVG DOM with batik. This DOM is then set as the Document | |||
| on the Foreign Object area in the Area Tree.</p><p>This DOM is then available to | |||
| be rendered by the renderer.</p><p>SVG is rendered in the renderers via an | |||
| XMLHandler in the FOUserAgent. This XML handler is used to render the SVG. The | |||
| SVG is rendered by using batik. Batik converts the SVG DOM into an internal | |||
| structure that can be drawn into a Graphics2D. So for PDF we use a | |||
| PDFGraphics2D to draw into.</p><p>This creates the necessary PDF information to | |||
| create the SVG image in the PDF document.</p><p>Most of the work is done in the | |||
| PDFGraphics2D class. There are also a few bridges that are plugged into batik | |||
| to provide different behaviour for some SVG elements.</p><s2 | |||
| title="Text Drawing"><p>Normally batik converts text into a set of curved | |||
| shapes. </p><p>This is handled as any other shapes when rendering to the output. This | |||
| is not always desirable as the shapes have very fine curves. This can cause the | |||
| output to look a bit bad in PDF and PS (it can be drawn properly but is not by | |||
| default). These curves also require much more data than the original | |||
| text.</p><p>To handle this there is a PDFTextElementBridge that is set when | |||
| using the bridge in batik. If the text is simple enough for the text to be | |||
| drawn in the PDF as with all other text then this sets the TextPainter to use | |||
| the PDFTextPainter. This inserts the text directly into the PDF using the | |||
| drawString method on the PDFGraphics2D.</p><p>Text is considered simple if the | |||
| font is available, the font size is useable and there are no tspans or other | |||
| complications. This can make the resulting PDF significantly | |||
| smaller.</p></s2><s2 title="PDF Links"><p>To support links in PDF another batik | |||
| element bridge is used. The PDFAElementBridge creates a PDFANode which inserts | |||
| a link into the PDF document via the PDFGraphics2D.</p><p>Since links are | |||
| positioned on the page without any transforms then we need to transform the | |||
| coordinates of the link area so that they match the current position of the a | |||
| element area. This transform may also need to account for the svg being | |||
| positioned on the page.</p></s2><s2 title="Images"><p>Images are normally drawn | |||
| into the PDFGraphics2D. This then creates a bitmap of the image data that can | |||
| be inserted into the PDF document. </p><p>As PDF can support jpeg images then another | |||
| element bridge is used so that the jpeg can be directly inserted into the | |||
| PDF.</p></s2><s2 title="PDF Transcoder"><p>Batik provides a mechanism to | |||
| convert SVG into various formats. Through FOP we can convert an SVG document | |||
| into a single paged PDF document. The page contains the SVG drawn as best as | |||
| possible on the page. There is a PDFDocumentGraphics2D that creates a | |||
| standalone PDF document with a single page. This is then drawn into by batik in | |||
| the same way as with the PDFGraphics2D.</p></s2><s2 | |||
| title="Other Outputs"><p>When rendering to AWT the SVG is simply drawn onto the | |||
| awt canvas using batik.</p><p>The PS Renderer uses a similar technique as the | |||
| PDF Renderer.</p><p>The SVG Renderer simply embeds the SVG inside an svg | |||
| element.</p></s2><s2 title="Associated Tasks"><ul><li>To get accurate drawing | |||
| pdf transparency is needed.</li><li>The drawRenderedImage methods need | |||
| implementing.</li><li>Handle colour space better.</li><li>Improve link handling | |||
| with pdf.</li><li>Improve image handling.</li></ul></s2></s1> | |||
| </body></document> | |||
+ 0
- 94
docs/design/understanding/understanding.xml
View File
| @@ -1,94 +0,0 @@ | |||
| <?xml version="1.0"?> | |||
| <!-- Overview --> | |||
| <document> | |||
| <header> | |||
| <title>Understanding FOP Design</title> | |||
| <subtitle>Tutorial series about Design Approach to FOP</subtitle> | |||
| <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> | |||
| </authors> | |||
| </header> | |||
| <body> | |||
| <s1 title="Understanding"> | |||
| <note> | |||
| The content of this <strong>Understanding series</strong> | |||
| was all taken from the interactive fop development mailing | |||
| list discussion . <br/> We strongly advise you to join this | |||
| mailing list and ask question about this series there. <br/> | |||
| You can subscribe to fop-dev@xml.apache.org by sending an | |||
| email to <link href= | |||
| "mailto:fop-dev-subscribe@xml.apache.org" | |||
| >fop-dev-subscribe@xml.apache.org</link>. <br/> You will | |||
| find more information about how to get involved <link href= | |||
| "http://xml.apache.org/fop/involved.html" | |||
| >there</link>.<br/> You can also read the <link href= | |||
| "http://marc.theaimsgroup.com/?l=fop-dev&r=1&w=2" | |||
| >archive</link> of the discussion list fop-dev to get an | |||
| idea of the issues being discussed. | |||
| </note> | |||
| <s2 title="Introduction"> | |||
| <p> | |||
| Welcome to the understanding series. This will be | |||
| a series of notes for developers to understand how FOP | |||
| works. We will | |||
| attempt to clarify the processes involved to go from xml(fo) | |||
| to pdf or other formats. Some areas will get more | |||
| complicated as we proceed. | |||
| </p> | |||
| </s2> | |||
| <s2 title="Overview"> | |||
| <p>FOP takes an xml file does its magic and then writes a document to a | |||
| stream.</p> | |||
| <p>xml -> [FOP] -> document</p> | |||
| <p>The document could be pdf, ps etc. or directed to a printer or the | |||
| screen. The principle remains the same. The xml document must be in the XSL:FO | |||
| format.</p> | |||
| <p>For convenience we provide a mechanism to handle XML+XSL as | |||
| input.</p> | |||
| <p>The xml document is always handled internally as SAX. The SAX events | |||
| are used to read the elements, attributes and text data of the FO document. | |||
| After the manipulation of the data the renderer writes out the pages in the | |||
| appropriate format. It may write as it goes, a page at a time or the whole | |||
| document at once. Once finished the document should contain all the data in the | |||
| chosen format ready for whatever use.</p></s2> | |||
| <s2 title="Stages"><p>The fo data goes through a few stages. Each piece | |||
| of data will generally go through the process in the same way but some | |||
| information may be used a number of times or in a different order. To reduce | |||
| memory one stage will start before the previous is completed.</p> | |||
| <p>SAX Handler -> FO Tree -> Layout Managers -> Area Tree | |||
| -> Render -> document</p> | |||
| <p>In the case of rtf, mif etc. <br/>SAX Handler -> FO Tree -> | |||
| Structure Renderer -> document</p> | |||
| <p>The FO Tree is constructed from the xml document. It is an internal | |||
| representation of the xml document and it is like a DOM with some differences. | |||
| The Layout Managers use the FO Tree do their layout stuff and create an Area | |||
| Tree. The Area Tree is a representation of the final result. It is a | |||
| representation of a set of pages containing the text and other graphics. The | |||
| Area Tree is then given to a Renderer. The Renderer can read the Area Tree and | |||
| convert the information into the render format. For example the PDF Renderer | |||
| creates a PDF Document. For each page in the Area Tree the renderer creates a | |||
| PDF Page and places the contents of the page into the PDF Page. Once a PDF Page | |||
| is complete then it can be written to the output stream.</p> | |||
| <p>For the structure documents the Structure listener will read | |||
| directly from the FO Tree and create the document. These documents do not need | |||
| the layout process or the Area Tree.</p></s2> | |||
| <s2 title="Associated Tasks"><p>Verify Structure Listener | |||
| concept.</p></s2> | |||
| <s2 title="Further Topics"> | |||
| <ul><li>XML parsing</li> | |||
| <li>FO Tree</li> | |||
| <li>Properties</li> | |||
| <li>Layout Managers</li> | |||
| <li>Layout Process</li> | |||
| <li>Handling Attributes</li> | |||
| <li>Area Tree</li> | |||
| <li>Renderers</li> | |||
| <li>Images</li> | |||
| <li>PDF Library</li> | |||
| <li>SVG</li> | |||
| </ul> | |||
| </s2> | |||
| </s1> </body></document> | |||
+ 0
- 106
docs/design/understanding/xml_parsing.xml
View File
| @@ -1,106 +0,0 @@ | |||
| <?xml version="1.0"?> | |||
| <document> | |||
| <header> | |||
| <title>XML Parsing</title> | |||
| <subtitle>All you wanted to know about XML Parsing !</subtitle> | |||
| <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> | |||
| </authors> | |||
| </header> | |||
| <body> | |||
| <s1 title="XML Parsing"><p>Since everyone knows the basics we can get | |||
| into the various stages starting with the XML handling.</p> | |||
| <s2 title="XML Input"><p>FOP can take the input XML in a number of ways: | |||
| </p> | |||
| <ul> | |||
| <li>SAX Events through SAX Handler | |||
| <ul> | |||
| <li> | |||
| <code>FOTreeBuilder</code> is the SAX Handler which is | |||
| obtained through <code>getContentHandler</code> on | |||
| <code>Driver</code>. | |||
| </li> | |||
| </ul> | |||
| </li> | |||
| <li> | |||
| DOM which is converted into SAX Events | |||
| <ul> | |||
| <li> | |||
| The conversion of a DOM tree is done via the | |||
| <code>render(Document)</code> method on | |||
| <code>Driver</code>. | |||
| </li> | |||
| </ul> | |||
| </li> | |||
| <li> | |||
| data source which is parsed and converted into SAX Events | |||
| <ul> | |||
| <li> | |||
| The <code>Driver</code> can take an | |||
| <code>InputSource</code> as input. This can use a | |||
| <code>Stream</code>, <code>String</code> etc. | |||
| </li> | |||
| </ul> | |||
| </li> | |||
| <li> | |||
| XML+XSLT which is transformed using an XSLT Processor and | |||
| the result is fired as SAX Events | |||
| <ul> | |||
| <li> | |||
| <code>XSLTInputHandler</code> is used as an | |||
| <code>InputSource</code> in the | |||
| render(<code>XMLReader</code>, | |||
| <code>InputSource</code>) method on | |||
| <code>Driver</code> | |||
| </li> | |||
| </ul> | |||
| </li> | |||
| </ul> | |||
| <p>The SAX Events which are fired on the SAX Handler, class | |||
| <code>FOTreeBuilder</code>, must represent an XSL:FO document. If not there will be an | |||
| error. Any problems with the XML being well formed are handled here.</p></s2> | |||
| <s2 title="Element Mappings"><p> The element mapping is a hashmap of all | |||
| the elements in a particular namespace. This makes it easy to create a | |||
| different object for each element. Element mappings are static to save on | |||
| memory. </p><p>To add an extension a developer can put in the classpath a jar | |||
| that contains the file <code>/META-INF/services/org.apache.fop.fo.ElementMapping</code>. | |||
| This must contain a line with the fully qualified name of a class that | |||
| implements the <em>org.apache.fop.fo.ElementMapping</em> interface. This will then be | |||
| loaded automatically at the start. Internal mappings are: FO, SVG and Extension | |||
| (pdf bookmarks)</p></s2> | |||
| <s2 title="Tree Building"><p>The SAX Events will fire all the information | |||
| for the document with start element, end element, text data etc. This | |||
| information is used to build up a representation of the FO document. To do this | |||
| for a namespace there is a set of element mappings. When an element + namepsace | |||
| mapping is found then it can create an object for that element. If the element | |||
| is not found then it creates a dummy object or a generic DOM for unknown | |||
| namespaces.</p> | |||
| <p>The object is then setup and then given attributes for the element. | |||
| For the FO Tree the attributes are converted into properties. The FO objects | |||
| use a property list mapping to convert the attributes into a list of properties | |||
| for the element. For other XML, for example SVG, a DOM of the XML is | |||
| constructed. This DOM can then be passed through to the renderer. Other element | |||
| mappings can be used in different ways, for example to create elements that | |||
| create areas during the layout process or setup information for the renderer | |||
| etc.</p> | |||
| <p> | |||
| While the tree building is mainly about creating the FO Tree | |||
| there are some stages that can propagate to the renderer. At | |||
| the end of a page sequence we know that all pages in the | |||
| page sequence can be laid out without being effected by any | |||
| further XML. The significance of this is that the FO Tree | |||
| for the page sequence may be able to be disposed of. The | |||
| end of the XML document also tells us that we can finalise | |||
| the output document. (The layout of individual pages is | |||
| accomplished by the layout managers page at a time; | |||
| i.e. they do not need to wait for the end of the page | |||
| sequence. The page may not yet be complete, however, | |||
| containing forward page number references, for example.) | |||
| </p> | |||
| </s2> | |||
| <s2 title="Associated Tasks"> | |||
| <ul><li>Error handling for xml not well formed.</li> | |||
| <li>Error handling for other XML parsing errors.</li><li>Developer | |||
| info for adding namespace handlers.</li></ul></s2></s1> | |||
| </body></document> | |||
Loading…