On 02 Sep 2009, at 20:22, Stephan Thesing wrote:
Hi Stephan
just a short status / question update.
I have added the fo:change-bar-begin/end elements with their
properties.
Validation is also implemented, but:
- In contrast to the other fo: elements, the change-bar-* elements
are allowed to occur everywhere, as long as they have an
fo:flow or fo:static-content ancestor.
Yep, that's what I was referring to, and AFAICT, it is not mandated
that the change-bar-begin and the corresponding change-bar-end appear
in the same flow/page-sequence.
All the elements do their content validation via validateChildNode()
(e.g. Block.java in o.a.fop.fo.flow).
As I didn't want to add acceptance of change-bar-* children to all
fo: elements under o.a.fop.fo.flow, I added to FNode.java a
validateChildNodeGlobal() function that performs the "global"
check for change-bar-* children and then calls
validateChildNode()
to perform the local check for each element.
in FOTreeBuilder.java this is then called instead of
validateChildNode().
The version of validateChildNodeGlobal() applicable for change bars
is added in FObj.java
Seems reasonable, although... validateChildNode() is more meant to
take care of very specific cases, mentioned in the definition of the
content model. Now I'm thinking: a change-bar-* is a neutral item that
is basically allowed anywhere, except as a child/descendant of a very
limited set of FOs that cannot appear as descendants of an fo:flow or
fo:static-content.
The requirement of a flow/static-content ancestor is specific to the
change-bar-* nodes, not to their parent/ancestor, so I'm not entirely
sure whether FObj is the right place to enforce that rule...
A common superclass ChangeBarNode for ChangeBarBegin and ChangeBarEnd
could take care of that 'validation' in its processNode()
implementation. The stacking-validation could probably be performed in
the same go. No changes necessary so high up in the class hierarchy.
To trigger correct validation when the eventual (parent) FObj calls
its validateChildNode() method, all that needs to be altered there, is
the addition of "change-bar-begin" and "change-bar-end" to the
isNeutralItem() method.
Validation of the stacking constraints of change-bar-begin and -end
are
also done.
Error messages and codes for validation errors are also already added.
What remains is layout and producing the change bar areas.
If I read the spec right, the intended semantics of the change-bar-
elements is the following:
<snip />
For me, that means that an element can be under the influence of
multiple change bars, naturally.
Indeed, and if no offset is specified the bars will be drawn over each
other.
<snip />
I'll get back on your further ideas ASAP.
Regards,
Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandr...@jabber.org
skype: adlm0608
---
