DO NOT REPLY [Bug 48548] FOP doesn't support change bar generation

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=48548

--- Comment #1 from Stephan Thesing <th...@gmx.de> 2010-02-16 18:49:44 UTC ---
Status update:
I have been working on the change bar implementation (on and off) and reached
a state where I see first results.

Summary of what has been implemented and how:
 - the change-bar-begin and change-bar-end element and attribute recognition
was added
 - the semantics of change bars is that every element between the
change-bar-begin and -end is "under the influence" of the change bar and every
area it
   produces should be decorated by a change bar with the form/placement given 
   with the change-bar-begin element 
   Thus, for every FO object, one has to keep track, which change bars (can be
    more than one) influence it.  I added that to FONode and as the vector of
    "active" change bars has to be kept globally added that to FOUserAgent.
   Thus, after .fo parsing, at each FObj we have the vector of change bars
    influencing the FObj.
 - For each area generated by an object ("influenced area")
    influenced by change bars, a change bar
    area has to added (for each such change bar). 
   I choose to implement the rendering of change bars in the Render (in 
    AbstractRenderer.java), as the placement of change bar areas is not
    decideable locally to each "influenced area" but rather relative to column
    start/end/left/right edges, which seemed easier to implement when the
    renderer iterates through all areas anyhow.
   Thus, the "influenced areas" only record the same vector of change bars that
    their generating layout manager (via the FObj associated to the 
     LayoutManager) had, when they are generated.
   I modified the code under oa.fop.layoutmgr.* to copy over the vector of 
    change bars to the Area, which was modified to have an additional vector 
    element.

 - In the AbstractRenderer, the code that produces output for Block or other 
   Areas was modified to draw the change bars, if any is attached to the area
    (i.e. the Area was an "influenced area").
   Also, the computation of the relevant places along columns, etc. is computed
    there.
   This last change needs information about the reference orientation and the
    writing mode, as change bar placement can depend on the binding edge being
    coincident with start or stop edge and on can be explicitly be placed on
    "left" and "right" edges.
   This amounts to quite some data to record at the ReferenceRegion and handled
    in the various constructors.

>From a memory footprint point of view, the additional effort needed by this
approach is a vector of change bars (the change bar objects itself are shared),
and one change bar object for each begin-change-bar element in the input.
In addition, a reference to this vector is attached at every Area (but the
vector itself is not copied).

A first implementation seems to work but has only been tested on "normal"
change bar placement (along the inner edge of a one-column layout).
No writing mode or orientation variations have been tried yet:-)


A diff with my set of changes will follow in another attachment to this PR
soon.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.