xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Delmelle <andreas.delme...@telenet.be>
Subject Re: Implementing Change bars
Date Wed, 02 Sep 2009 20:04:57 GMT
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: mandreas@jabber.org
skype: adlm0608

---


Mime
View raw message