Properties$AbsolutePosition

Date: Mon, 2 Dec 2002 12:00:11 +0000 (+0000) Subject: fixed some errors X-Git-Tag: Alt-Design-integration-base~283 X-Git-Url: https://source.dussan.org/?a=commitdiff_plain;h=0897c4f0d2cf131b08876e7b9242b913e195f6f8;p=xmlgraphics-fop.git fixed some errors git-svn-id: https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk@195702 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/src/documentation/content/xdocs/design/alt.design/AbsolutePosition.png.xml b/src/documentation/content/xdocs/design/alt.design/AbsolutePosition.png.xml index 46a6999a3..fbd479173 100644 --- a/src/documentation/content/xdocs/design/alt.design/AbsolutePosition.png.xml +++ b/src/documentation/content/xdocs/design/alt.design/AbsolutePosition.png.xml @@ -13,7 +13,7 @@

Properties$AbsolutePosition -

diff --git a/src/documentation/content/xdocs/design/alt.design/BorderCommonStyle.png.xml b/src/documentation/content/xdocs/design/alt.design/BorderCommonStyle.png.xml index e9fad3d77..71f90c1d6 100644 --- a/src/documentation/content/xdocs/design/alt.design/BorderCommonStyle.png.xml +++ b/src/documentation/content/xdocs/design/alt.design/BorderCommonStyle.png.xml @@ -13,7 +13,7 @@

Properties$BorderCommonStyle -

diff --git a/src/documentation/content/xdocs/design/alt.design/PropNames.png.xml b/src/documentation/content/xdocs/design/alt.design/PropNames.png.xml index 6f552009b..1a2b92f2f 100644 --- a/src/documentation/content/xdocs/design/alt.design/PropNames.png.xml +++ b/src/documentation/content/xdocs/design/alt.design/PropNames.png.xml @@ -5,6 +5,7 @@

..fo.PropNames diagram + @@ -12,7 +13,7 @@

PropNames.class -

diff --git a/src/documentation/content/xdocs/design/alt.design/Properties.png.xml b/src/documentation/content/xdocs/design/alt.design/Properties.png.xml index 8bcf88943..a8c2497d5 100644 --- a/src/documentation/content/xdocs/design/alt.design/Properties.png.xml +++ b/src/documentation/content/xdocs/design/alt.design/Properties.png.xml @@ -13,7 +13,7 @@

Properties.class -

diff --git a/src/documentation/content/xdocs/design/alt.design/PropertyConsts.png.xml b/src/documentation/content/xdocs/design/alt.design/PropertyConsts.png.xml index 2e2763026..d2da2692c 100644 --- a/src/documentation/content/xdocs/design/alt.design/PropertyConsts.png.xml +++ b/src/documentation/content/xdocs/design/alt.design/PropertyConsts.png.xml @@ -13,7 +13,7 @@

PropertyConsts.class -

diff --git a/src/documentation/content/xdocs/design/alt.design/VerticalAlign.png.xml b/src/documentation/content/xdocs/design/alt.design/VerticalAlign.png.xml index 400d43cf7..14e835347 100644 --- a/src/documentation/content/xdocs/design/alt.design/VerticalAlign.png.xml +++ b/src/documentation/content/xdocs/design/alt.design/VerticalAlign.png.xml @@ -13,7 +13,7 @@

Properties$VerticalAlign -

diff --git a/src/documentation/content/xdocs/design/alt.design/alt-properties.xml b/src/documentation/content/xdocs/design/alt.design/alt-properties.xml new file mode 100644 index 000000000..ce5396618 --- /dev/null +++ b/src/documentation/content/xdocs/design/alt.design/alt-properties.xml @@ -0,0 +1,172 @@ + + + + +

+ Implementing Properties + + + +

+ +

+ An alternative properties implementation + + 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. + +

+ Property handling is complex and expensive. Varying numbers of + properties apply to individual Flow Objects + (FOs) in the FO + tree 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. +

+ + (XSL 1.0 Rec) 5.1.4 Inheritance + ...The inheritable properties can be placed on any formatting + object. + +

+ Even if the value is not inheritable, it may be accessed by + its children through the inherit keyword or the + from-parent() core function, and potentially by + any of its descendents through the + from-nearest-specified-value() core function. +

+ In addition to the assigned values of properties, almost every + property has an initial value which is used + when no value has been assigned. +

+ The history problem +

+ The difficulty and expense of handling properties comes from + this univeral inheritance possibility. The list of properties + which are assigned values on any particular FO + element will not generally be large, but a current value is + required for each property which applies to the FO + being processed. +

+ The environment from which these values may be selected + includes, for each FO, for each applicable property, + the value assigned on this FO, the value which + applied to the parent of this FO, the nearest value + specified on an ancestor of this element, and the initial + value of the property. +

+ Data requirement and structure +

+ This determines the minimum set of properties and associated + property value assignments that is necessary for the + processing of any individual FO. Implicit in this + set is the set of properties and associated values, + effective on the current FO, that were assigned on + that FO. +

+ 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. +

+ Stack considerations +

+ 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 + FO 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 FO tree. +

+ The complication is that, for elements which are not + automatically inherited, when an FO is encountered + which does not 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. +

+ 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. +

+ Stack implementation +

+ Initial attempts at this implementation have used + LinkedLists as the stacks, on the assumption + that +

random access would not be required
+ pushing and popping of list elements requires nearly + constant (low) time +
no penalty for first addition to an empty list
efficient access to both bottom and top of stack

+ 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 + ArrayLists instead. +

+ Class vs instance +

+ 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 FO, and, in the other + direction, the membership of the property in the set of + properties for which an FO has defined values. +

+ 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 + FO. If the property stack is maintained in + parallel with a stack of FOs, even that link is + implicit in the stack position. +

+ Next: property classes overview. +

+ + + diff --git a/src/documentation/content/xdocs/design/alt.design/alt.properties.xml b/src/documentation/content/xdocs/design/alt.design/alt.properties.xml deleted file mode 100644 index a1e7fcf09..000000000 --- a/src/documentation/content/xdocs/design/alt.design/alt.properties.xml +++ /dev/null @@ -1,172 +0,0 @@ - - - - -

- Implementing Properties - - - -

- -

- An alternative properties implementation - - 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. - -

- Property handling is complex and expensive. Varying numbers of - properties apply to individual Flow Objects - (FOs) in the FO - tree 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. -

- - (XSL 1.0 Rec) 5.1.4 Inheritance - ...The inheritable properties can be placed on any formatting - object. - -

- Even if the value is not inheritable, it may be accessed by - its children through the inherit keyword or the - from-parent() core function, and potentially by - any of its descendents through the - from-nearest-specified-value() core function. -

- In addition to the assigned values of properties, almost every - property has an initial value which is used - when no value has been assigned. -

- The history problem -

- The difficulty and expense of handling properties comes from - this univeral inheritance possibility. The list of properties - which are assigned values on any particular FO - element will not generally be large, but a current value is - required for each property which applies to the FO - being processed. -

- The environment from which these values may be selected - includes, for each FO, for each applicable property, - the value assigned on this FO, the value which - applied to the parent of this FO, the nearest value - specified on an ancestor of this element, and the initial - value of the property. -

- Data requirement and structure -

- This determines the minimum set of properties and associated - property value assignments that is necessary for the - processing of any individual FO. Implicit in this - set is the set of properties and associated values, - effective on the current FO, that were assigned on - that FO. -

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

- Stack considerations -

- 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 - FO 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 FO tree. -

- The complication is that, for elements which are not - automatically inherited, when an FO is encountered - which does not 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. -

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

- Stack implementation -

- Initial attempts at this implementation have used - LinkedLists as the stacks, on the assumption - that -

- - -

random access would not be required

- pushing and popping of list elements requires nearly - constant (low) time -

no penalty for first addition to an empty list

efficient access to both bottom and top of stack

- -

- 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 - ArrayLists instead. -

- Class vs instance -

- 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 FO, and, in the other - direction, the membership of the property in the set of - properties for which an FO has defined values. -

- 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 - FO. If the property stack is maintained in - parallel with a stack of FOs, even that link is - implicit in the stack position. -

- Next: property classes overview. -

- - - diff --git a/src/documentation/content/xdocs/design/alt.design/book.xml b/src/documentation/content/xdocs/design/alt.design/book.xml index 2324a6d33..864c3989b 100644 --- a/src/documentation/content/xdocs/design/alt.design/book.xml +++ b/src/documentation/content/xdocs/design/alt.design/book.xml @@ -18,7 +18,7 @@

- +

diff --git a/src/documentation/content/xdocs/design/alt.design/classes-overview.xml b/src/documentation/content/xdocs/design/alt.design/classes-overview.xml index b5e2be845..c0c7a5fac 100644 --- a/src/documentation/content/xdocs/design/alt.design/classes-overview.xml +++ b/src/documentation/content/xdocs/design/alt.design/classes-overview.xml @@ -82,7 +82,7 @@ static data and methods have been split tentatively into three:

PropNames