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


Andreas Delmelle
jabber: mandr...@jabber.org
skype: adlm0608


Reply via email to