arved 02/03/17 09:24:11 Added: docs/design/alt.design AbsolutePosition.png BorderCommonStyle.png parserPersistence.png processPlumbing.png Properties.png PropertyClasses.png PropertyConsts.png PropertyStaticsOverview.png property-super-classes-full.png PropNames.png SAXParsing.png VerticalAlign.png XML-event-buffer.png XMLEventQueue.png xmlevent-queue.png AbsolutePosition.dia processPlumbing.dia Properties.dia PropertyClasses.dia PropertyConsts.dia PropertyStaticsOverview.dia property-super-classes-full.dia PropNames.dia SAXParsing.dia VerticalAlign.dia XML-event-buffer.dia XMLEventQueue.dia xmlevent-queue.dia AbsolutePosition.png.xml alt.properties.xml book.xml BorderCommonStyle.png.xml classes-overview.xml properties-classes.xml Properties.png.xml PropertyConsts.png.xml propertyExpressions.xml PropNames.png.xml VerticalAlign.png.xml xml-parsing.xml dirlist.html Log: Extra design commentary Revision Changes Path 1.1 xml-fop/docs/design/alt.design/AbsolutePosition.png <<Binary file>> 1.1 xml-fop/docs/design/alt.design/BorderCommonStyle.png <<Binary file>> 1.1 xml-fop/docs/design/alt.design/parserPersistence.png <<Binary file>> 1.1 xml-fop/docs/design/alt.design/processPlumbing.png <<Binary file>> 1.1 xml-fop/docs/design/alt.design/Properties.png <<Binary file>> 1.1 xml-fop/docs/design/alt.design/PropertyClasses.png <<Binary file>> 1.1 xml-fop/docs/design/alt.design/PropertyConsts.png <<Binary file>> 1.1 xml-fop/docs/design/alt.design/PropertyStaticsOverview.png <<Binary file>> 1.1 xml-fop/docs/design/alt.design/property-super-classes-full.png <<Binary file>> 1.1 xml-fop/docs/design/alt.design/PropNames.png <<Binary file>> 1.1 xml-fop/docs/design/alt.design/SAXParsing.png <<Binary file>> 1.1 xml-fop/docs/design/alt.design/VerticalAlign.png <<Binary file>> 1.1 xml-fop/docs/design/alt.design/XML-event-buffer.png <<Binary file>> 1.1 xml-fop/docs/design/alt.design/XMLEventQueue.png <<Binary file>> 1.1 xml-fop/docs/design/alt.design/xmlevent-queue.png <<Binary file>> 1.1 xml-fop/docs/design/alt.design/AbsolutePosition.dia <<Binary file>> 1.1 xml-fop/docs/design/alt.design/processPlumbing.dia <<Binary file>> 1.1 xml-fop/docs/design/alt.design/Properties.dia <<Binary file>> 1.1 xml-fop/docs/design/alt.design/PropertyClasses.dia <<Binary file>> 1.1 xml-fop/docs/design/alt.design/PropertyConsts.dia <<Binary file>> 1.1 xml-fop/docs/design/alt.design/PropertyStaticsOverview.dia <<Binary file>> 1.1 xml-fop/docs/design/alt.design/property-super-classes-full.dia <<Binary file>> 1.1 xml-fop/docs/design/alt.design/PropNames.dia <<Binary file>> 1.1 xml-fop/docs/design/alt.design/SAXParsing.dia <<Binary file>> 1.1 xml-fop/docs/design/alt.design/VerticalAlign.dia <<Binary file>> 1.1 xml-fop/docs/design/alt.design/XML-event-buffer.dia <<Binary file>> 1.1 xml-fop/docs/design/alt.design/XMLEventQueue.dia <<Binary file>> 1.1 xml-fop/docs/design/alt.design/xmlevent-queue.dia <<Binary file>> 1.1 xml-fop/docs/design/alt.design/AbsolutePosition.png.xml Index: AbsolutePosition.png.xml =================================================================== <?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="[EMAIL PROTECTED]"/> </authors> </header> <body> <!-- one of (anchor s1) --> <s1 title="Properties$AbsolutePosition"> <figure src="AbsolutePosition.png" alt="AbsolutePosition diagram"/> </s1> </body> </document> 1.1 xml-fop/docs/design/alt.design/alt.properties.xml Index: alt.properties.xml =================================================================== <?xml version="1.0" encoding="ISO-8859-1"?> <!-- $Id: alt.properties.xml,v 1.1 2002/03/17 17:24:10 arved Exp $ --> <!-- <!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd"> --> <document> <header> <title>Implementing Properties</title> <authors> <person id="pbw" name="Peter B. West" email="[EMAIL PROTECTED]"/> </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"> </s2> <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 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> 1.1 xml-fop/docs/design/alt.design/book.xml Index: book.xml =================================================================== <?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.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"/> </book> 1.1 xml-fop/docs/design/alt.design/BorderCommonStyle.png.xml Index: BorderCommonStyle.png.xml =================================================================== <?xml version="1.0" encoding="ISO-8859-1"?> <!-- $Id: BorderCommonStyle.png.xml,v 1.1 2002/03/17 17:24:10 arved Exp $ --> <!-- <!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd"> --> <document> <header> <title>BorderCommonStyle diagram</title> <authors> <person id="pbw" name="Peter B. West" email="[EMAIL PROTECTED]"/> </authors> </header> <body> <!-- one of (anchor s1) --> <s1 title="Properties$BorderCommonStyle"> <figure src="BorderCommonStyle.png" alt="BorderCommonStyle diagram"/> </s1> </body> </document> 1.1 xml-fop/docs/design/alt.design/classes-overview.xml Index: classes-overview.xml =================================================================== <?xml version="1.0" encoding="ISO-8859-1"?> <!-- $Id: classes-overview.xml,v 1.1 2002/03/17 17:24:10 arved Exp $ --> <!-- <!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="[EMAIL PROTECTED]"/> </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> 1.1 xml-fop/docs/design/alt.design/properties-classes.xml Index: properties-classes.xml =================================================================== <?xml version="1.0" encoding="ISO-8859-1"?> <!-- $Id: properties-classes.xml,v 1.1 2002/03/17 17:24:10 arved Exp $ --> <!-- <!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd"> --> <document> <header> <title>Properties$classes</title> <authors> <person name="Peter B. West" email="[EMAIL PROTECTED]"/> </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> 1.1 xml-fop/docs/design/alt.design/Properties.png.xml Index: Properties.png.xml =================================================================== <?xml version="1.0" encoding="ISO-8859-1"?> <!-- $Id: Properties.png.xml,v 1.1 2002/03/17 17:24:10 arved Exp $ --> <!-- <!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="[EMAIL PROTECTED]"/> </authors> </header> <body> <!-- one of (anchor s1) --> <s1 title="Properties.class"> <figure src="Properties.png" alt="Properties.class diagram"/> </s1> </body> </document> 1.1 xml-fop/docs/design/alt.design/PropertyConsts.png.xml Index: PropertyConsts.png.xml =================================================================== <?xml version="1.0" encoding="ISO-8859-1"?> <!-- $Id: PropertyConsts.png.xml,v 1.1 2002/03/17 17:24:10 arved Exp $ --> <!-- <!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="[EMAIL PROTECTED]"/> </authors> </header> <body> <!-- one of (anchor s1) --> <s1 title="PropertyConsts.class"> <figure src="PropertyConsts.png" alt="PropertyConsts.class diagram"/> </s1> </body> </document> 1.1 xml-fop/docs/design/alt.design/propertyExpressions.xml Index: propertyExpressions.xml =================================================================== <?xml version="1.0" encoding="ISO-8859-1"?> <!-- $Id: propertyExpressions.xml,v 1.1 2002/03/17 17:24:10 arved Exp $ --> <!-- <!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="[EMAIL PROTECTED]"/> </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> 1.1 xml-fop/docs/design/alt.design/PropNames.png.xml Index: PropNames.png.xml =================================================================== <?xml version="1.0" encoding="ISO-8859-1"?> <!-- $Id: PropNames.png.xml,v 1.1 2002/03/17 17:24:10 arved Exp $ --> <!-- <!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="[EMAIL PROTECTED]"/> </authors> </header> <body> <!-- one of (anchor s1) --> <s1 title="PropNames.class"> <figure src="PropNames.png" alt="PropNames.class diagram"/> </s1> </body> </document> 1.1 xml-fop/docs/design/alt.design/VerticalAlign.png.xml Index: VerticalAlign.png.xml =================================================================== <?xml version="1.0" encoding="ISO-8859-1"?> <!-- $Id: VerticalAlign.png.xml,v 1.1 2002/03/17 17:24:10 arved Exp $ --> <!-- <!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd"> --> <document> <header> <title>VerticalAlign diagram</title> <authors> <person id="pbw" name="Peter B. West" email="[EMAIL PROTECTED]"/> </authors> </header> <body> <!-- one of (anchor s1) --> <s1 title="Properties$VerticalAlign"> <figure src="VerticalAlign.png" alt="VerticalAlign diagram"/> </s1> </body> </document> 1.1 xml-fop/docs/design/alt.design/xml-parsing.xml Index: xml-parsing.xml =================================================================== <?xml version="1.0" encoding="ISO-8859-1"?> <!-- $Id: xml-parsing.xml,v 1.1 2002/03/17 17:24:10 arved Exp $ --> <!-- <!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd"> --> <document> <header> <title>Integrating XML Parsing</title> <authors> <person name="Peter B. West" email="[EMAIL PROTECTED]"/> </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 heirarchical 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> 1.1 xml-fop/docs/design/alt.design/dirlist.html Index: dirlist.html =================================================================== <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <title>alt.design</title> </head> <body> <h3>Directory listing of alt.design</h3> <hr> <pre><code> drwxrwxr-x 2 pbw pbw 4096 Jan 31 17:58 . drwxrwxr-x 5 pbw pbw 4096 Jan 31 17:57 <a href="../dirlist.html">..</a> -rw-rw-r-- 1 pbw pbw 949 Jan 25 17:31 <a href="AbsolutePosition.dia">AbsolutePosition.dia</a> -rw-rw-r-- 1 pbw pbw 4890 Jan 25 17:31 <a href="AbsolutePosition.png">AbsolutePosition.png</a> -rw-r--r-- 1 pbw pbw 579 Jan 25 23:47 <a href="AbsolutePosition.png.xml">AbsolutePosition.png.xml</a> -rw-rw-r-- 1 pbw pbw 4140 Jan 25 17:31 <a href="BorderCommonStyle.png">BorderCommonStyle.png</a> -rw-r--r-- 1 pbw pbw 584 Jan 26 12:29 <a href="BorderCommonStyle.png.xml">BorderCommonStyle.png.xml</a> -rw-rw-r-- 1 pbw pbw 807 Jan 25 17:31 <a href="PropNames.dia">PropNames.dia</a> -rw-rw-r-- 1 pbw pbw 3428 Jan 25 17:31 <a href="PropNames.png">PropNames.png</a> -rw-r--r-- 1 pbw pbw 551 Jan 25 23:48 <a href="PropNames.png.xml">PropNames.png.xml</a> -rw-rw-r-- 1 pbw pbw 1900 Jan 25 17:31 <a href="Properties.dia">Properties.dia</a> -rw-rw-r-- 1 pbw pbw 32437 Jan 25 17:31 <a href="Properties.png">Properties.png</a> -rw-r--r-- 1 pbw pbw 556 Jan 25 23:48 <a href="Properties.png.xml">Properties.png.xml</a> -rw-rw-r-- 1 pbw pbw 2180 Jan 25 17:31 <a href="PropertyClasses.dia">PropertyClasses.dia</a> -rw-rw-r-- 1 pbw pbw 17581 Jan 25 17:31 <a href="PropertyClasses.png">PropertyClasses.png</a> -rw-rw-r-- 1 pbw pbw 1573 Jan 25 17:31 <a href="PropertyConsts.dia">PropertyConsts.dia</a> -rw-rw-r-- 1 pbw pbw 20379 Jan 25 17:31 <a href="PropertyConsts.png">PropertyConsts.png</a> -rw-r--r-- 1 pbw pbw 575 Jan 25 23:47 <a href="PropertyConsts.png.xml">PropertyConsts.png.xml</a> -rw-rw-r-- 1 pbw pbw 1333 Jan 25 17:31 <a href="PropertyStaticsOverview.dia">PropertyStaticsOverview.dia</a> -rw-rw-r-- 1 pbw pbw 7503 Jan 25 17:31 <a href="PropertyStaticsOverview.png">PropertyStaticsOverview.png</a> -rw-rw-r-- 1 pbw pbw 3068 Jan 25 17:31 <a href="SAXParsing.dia">SAXParsing.dia</a> -rw-rw-r-- 1 pbw pbw 24482 Jan 25 17:31 <a href="SAXParsing.png">SAXParsing.png</a> -rw-rw-r-- 1 pbw pbw 964 Jan 25 17:31 <a href="VerticalAlign.dia">VerticalAlign.dia</a> -rw-rw-r-- 1 pbw pbw 7091 Jan 25 17:31 <a href="VerticalAlign.png">VerticalAlign.png</a> -rw-r--r-- 1 pbw pbw 565 Jan 25 23:48 <a href="VerticalAlign.png.xml">VerticalAlign.png.xml</a> -rw-rw-r-- 1 pbw pbw 2004 Jan 25 17:31 <a href="XML-event-buffer.dia">XML-event-buffer.dia</a> -rw-rw-r-- 1 pbw pbw 20415 Jan 25 17:31 <a href="XML-event-buffer.png">XML-event-buffer.png</a> -rw-rw-r-- 1 pbw pbw 2322 Jan 25 17:31 <a href="XMLEventQueue.dia">XMLEventQueue.dia</a> -rw-rw-r-- 1 pbw pbw 11643 Jan 25 17:31 <a href="XMLEventQueue.png">XMLEventQueue.png</a> -rw-r--r-- 1 pbw pbw 6584 Jan 26 11:56 <a href="alt.properties.xml">alt.properties.xml</a> -rw-rw-r-- 1 pbw pbw 1152 Jan 25 17:31 <a href="book.xml">book.xml</a> -rw-r--r-- 1 pbw pbw 7834 Jan 26 13:07 <a href="classes-overview.xml">classes-overview.xml</a> -rw-rw-r-- 1 pbw pbw 8330 Jan 25 17:31 <a href="parserPersistence.png">parserPersistence.png</a> -rw-rw-r-- 1 pbw pbw 1974 Jan 25 17:31 <a href="processPlumbing.dia">processPlumbing.dia</a> -rw-rw-r-- 1 pbw pbw 8689 Jan 25 17:31 <a href="processPlumbing.png">processPlumbing.png</a> -rw-r--r-- 1 pbw pbw 5123 Jan 26 11:58 <a href="properties-classes.xml">properties-classes.xml</a> -rw-rw-r-- 1 pbw pbw 3115 Jan 25 17:31 <a href="property-super-classes-full.dia">property-super-classes-full.dia</a> -rw-rw-r-- 1 pbw pbw 89360 Jan 25 17:31 <a href="property-super-classes-full.png">property-super-classes-full.png</a> -rw-r--r-- 1 pbw pbw 10221 Jan 25 23:49 <a href="propertyExpressions.xml">propertyExpressions.xml</a> -rw-r--r-- 1 pbw pbw 9361 Jan 26 11:59 <a href="xml-parsing.xml">xml-parsing.xml</a> -rw-rw-r-- 1 pbw pbw 2655 Jan 25 17:31 <a href="xmlevent-queue.dia">xmlevent-queue.dia</a> -rw-rw-r-- 1 pbw pbw 12326 Jan 25 17:31 <a href="xmlevent-queue.png">xmlevent-queue.png</a> </code></pre> <hr> </body> </html>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]