https://issues.apache.org/bugzilla/show_bug.cgi?id=48548
--- Comment #1 from Stephan Thesing <[email protected]> 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.
