Re: Implementing Change bars

[Stephan Thesing]

Hello,

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

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:
 - for all elements generating areas that are under the influence of
 a change bar, add fixed areas as tall as the generated areas and
 placed beside the column of that area as given by the change bar
 properties.
 - being under the influence of  a change bar is defined by the file
order of elements in the input.
   I.e., any element between a change-bar-start and corresponding 
change-bar-end (same class) is influenced by that change bar.
   For me, that means that an element can be under the influence of multiple 
change bars, naturally.

My idea is now along the following lines:
 - Remember for each element during parsing the change bars it is influenced by.
 - After layout, go over all areas produced by those influenced elements
and add the areas for the change bars (thus, only an area with proper
 border attributes).

Can this be realizes in such a way in FOP?

I appreciate any comments and suggestions!

I will be able to produce a first diff of my code this weekend.

Best regards...
  Stephan



 - retrieving the start- and end locations of the bars during layout
   (org.apache.fop.layoutmgr)
 - creating the appropriate areas (will probably have to be done in
   o.a.f.layoutmgr.PageSequenceLayoutManager)
 
 That should be enough to get you started. If you have any question, see
 you on fop-dev!
 
 Vincent

-- 
Dr.-Ing. Stephan Thesing
Elektrastr. 50
81925 München
GERMANY

Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

Re: Implementing Change bars

[Andreas Delmelle]

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

---