Victor Mote wrote:
Peter B. West wrote:
Glen Mazza wrote:
--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
See above. In alt.design, all compounds are
shorthands, and all
shorthands are presumed to have been resolved into
their components
during FO Tree building.
BTW, does Alt-Design already resolve the cases where
*both* a shorthand and one of its included components
are specified? I.e., (usually, I believe), disregard
the shorthand value for that component and use its
explicitly given value instead?
It's in the ordering of the properties. There is a simply for loop to
process properties (attributes, in fact) defined on an FO. The order of
definition ensures the correct order of evaluation - shorthand first,
then any individual properties. The same goes for corresponding
properties, when I get around to doing them. Check the order of
properties in PropNames.java.
I don't know how to reconcile this with your previous posting:
See above. In alt.design, all compounds are shorthands, and all
shorthands are presumed to have been resolved into their components
during FO Tree building.
The previous posting seems to indicate that the properties have been
decomposed, the chronologically latter posting seems to indicate that the
shorthand retains its shorthand character. The critical thing here is that
the API not even allow anybody to ask about shorthand or compound
properties. The API should allow requests only for the decomposed
properties, and the FO Tree should resolve all of this before passing a
value back.
The ordering is necessary to ensure that the FO attributes are processed
in the correct sequence. When the properties on a particular node and
its subtree are fully parsed, the shorthands and compounds will have
been expanded, and the minimal property set for the stable FO tree is
constructed. See makeSparsePropsSet() in FONode.java at
http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-fop/src/java/org/apache/fop/fo/FONode.java?content-type=text%2Fplain&rev=1.2.2.1
Within getPropertyValue() these situations are discriminated, according
to the comments on
private PropertyValue[] propertySet;
When the properties for this value are still being resolved,
getPropertyValue() will resolve inheritance and initial values. During
this process, shorthands and compounds will be resolved. At the time
the subtree of the FONode has been constructed, the property set of the
node will be reduced (by makeSparsePropsSet()), and the shorthands and
compounds will be eliminated. A call to getPropertyValue() specifying
such a property will presently, IIRC, throw an exception. If necessary,
that can be adjusted to return a NoType PropertyValue, but the
assumption is that by this stage, anything calling for a resolved
property will be aware of which properties are valid on the node.
In either case, any other method which requests such a value is going to
get short shrift. I think that covers the last couple of sentences in
your comment above.
Basically, shorthands, etc, get resolved and eliminated from the valid
property set.
Peter
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
