diff options
| author | Peter Bernard West <pbwest@apache.org> | 2002-12-27 07:48:56 +0000 |
|---|---|---|
| committer | Peter Bernard West <pbwest@apache.org> | 2002-12-27 07:48:56 +0000 |
| commit | b3659d237d0d1c8e67cd6c681e2e00f60a4d9d6b (patch) | |
| tree | 7a9edc555ac7c7d3ed492bfd50dd4032ac2c8f58 | |
| parent | 2fe04c08178c8401c9275b0ea9874924cadaa8e5 (diff) | |
| download | xmlgraphics-fop-b3659d237d0d1c8e67cd6c681e2e00f60a4d9d6b.tar.gz xmlgraphics-fop-b3659d237d0d1c8e67cd6c681e2e00f60a4d9d6b.zip | |
WIP
git-svn-id: https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk@195803 13f79535-47bb-0310-9956-ffa450edef68
3 files changed, 144 insertions, 15 deletions
diff --git a/src/documentation/content/xdocs/design/alt.design/properties/PropertyConsts-class.xml b/src/documentation/content/xdocs/design/alt.design/properties/PropertyConsts-class.xml index 3ae5730a1..9a90267fd 100644 --- a/src/documentation/content/xdocs/design/alt.design/properties/PropertyConsts-class.xml +++ b/src/documentation/content/xdocs/design/alt.design/properties/PropertyConsts-class.xml @@ -12,11 +12,11 @@ <section> <title>Introduction</title> <p> - <fork href= "../PropertyConsts.html" >This class</fork>, and the - singleton object which is <fork href= + <fork href= "../PropertyConsts.html" >This class</fork>, and + the singleton object which is <fork href= "../PropertyConsts.html#pconsts" >generated by the static initializer</fork>, is essentially a repository of the static - data from the <property> classes of + data from the property classes of <code>org.apache.fop.fo.property</code>, and a common point of access for the methods of those classes. </p> diff --git a/src/documentation/content/xdocs/design/alt.design/properties/book.xml b/src/documentation/content/xdocs/design/alt.design/properties/book.xml index f3d677e15..4cb6871b0 100644 --- a/src/documentation/content/xdocs/design/alt.design/properties/book.xml +++ b/src/documentation/content/xdocs/design/alt.design/properties/book.xml @@ -13,8 +13,11 @@ </menu> <menu label="Alt properties"> <menu-item label="Introduction" href="index.html"/> + <menu-item label="Classes overview" href="classes-overview.html"/> <menu-item label="PropertyConsts" href="PropertyConsts-class.html"/> - <menu-item label="Data Handling" href="property-data.html"/> - <menu-item label="Methods Access" href="property-methods.html"/> + <menu-item label="Simple Properties" href="simple-properties.html"/> + <menu-item label="getInitialValue" href="getInitialValue.html"/> + <menu-item label="Enumerated data" href="enumerated-values.html"/> + <menu-item label="Property parsing" href="propertyExpressions.html"/> </menu> </book> diff --git a/src/documentation/content/xdocs/design/alt.design/properties/index.xml b/src/documentation/content/xdocs/design/alt.design/properties/index.xml index 6132f1884..9414aa82c 100644 --- a/src/documentation/content/xdocs/design/alt.design/properties/index.xml +++ b/src/documentation/content/xdocs/design/alt.design/properties/index.xml @@ -2,26 +2,152 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/resources/schema/dtd/document-v11.dtd"> -<!-- $Id$ --> - <document> <header> - <title>FOP Alternative Design Properties Notes</title> - <version>$Revision$ $Name$</version> + <title>Implementing Properties</title> <authors> - <person name="Peter B. West" email="pbwest@powerup.com.au"/> + <person id="pbw" name="Peter B. West" email="pbwest@powerup.com.au"/> </authors> </header> - <body> <section> - <title>Alt Design Properties Notes</title> + <title>An alternative properties implementation</title> + <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. + </note> + <p> + Property handling is complex and expensive. Varying numbers of + properties <strong>apply</strong> 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> + <section> + <title>The history problem</title> + <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>, <strong>for each applicable + property</strong>, 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> + </section> + <section> + <title>The construction hierarchy</title> + <p> + Properties are resoved in the <strong>FO tree</strong> in a + strictly hierarchical manner. Nodes are detected in the + input in a <strong>pre-order</strong> traversal, and are + built in the same order. This imples that there are two + phases, or states, of property resolution and construction. + Any particular FO node is either in a state of constructing + its own subtree, or in a stable state where the subtree + construction is complete. These states have differenct data + requirements. + </p> + <dl> + <dt>Subtree building</dt> + <dd> + In this state, all properties defined on this node, or any + of its ancestors must be available to the subtree. In + effect, any property defined on this node must be + available to its descendants, as all properties defined on + any ancestor are available to this node. + </dd> + <dt>Stable: subtree building complete</dt> + <dd> + In this state, only the properties <strong>applicable to + this node</strong> need be available. + </dd> + </dl> + </section> + <section> + <title>Representing properties: <property> classes</title> + <section> + <title>Class vs instance</title> + <p> + What information is required of <property> objects? + More particularly, what information is particular to the + <property> classes, and what to the instantiated + objects? The answer to this question depend largely on + how the <property> objects are used in the context + of layout and Area tree construction. The approach taken + in this implementation is that properties are simply flags + on certain data values associated with FOs. The semantics + of these flags are determined within the layout engine. + </p> + <p> + Certain constant information attaches to individual + <property> classes. This information is detailed in + the descriptions of individual properties in <em>Section + 7</em> of the specification. Such information is + represented in <strong>class</strong> fields and data + structures within the classes. + </p> + <p> + The "instance" information content of a <property> + is: + </p> + <ul> + <li> + explicitly, the <code>PropertyValue</code> datum of + the property, and + </li> + <li> + implicitly, the <strong>Flow Object</strong> to which + the property is attached. + </li> + </ul> + <p> + Properties, then, serve essentially to link <em>FO + instances</em> with <em>PropertyValue instances</em>, + attaching certain invariant semantic markers to the + PropertyValues in the process. In this implementation, + these functions can be realised entirely within the + <property> <strong>classes</strong> themselves, + without the need to instantiate any objects. In practice, + <strong><property> singletons</strong> are + instantiated to make access to some invariants simpler. + </p> + </section> + </section> <p> - This section includes more detailed notes on the classes which - are involved in the implementation of FO properties. + <strong>Next:</strong> <link href="classes-overview.html" + >property classes overview.</link> </p> </section> - </body> </document> |