Stephan Thesing wrote:
Dear all,
sorry for the long delay in answering.
Hi Stephan,
thanks for looking into this! Change bars would be a useful feature
addition to FOP.
Having had some time in the last days to actually continue working
on the change bar stuff:
+ parsing and validating the fo:change-bar-begin and fo:change-bar-end
elements works (including properties)
+ attaching to all fo: elements that are between fo:change-bar-begin
and fo:change-bar-end elements the vector of change bars that
affect the element is implemented
If I understand the FO standard right, then for each area generated
by a FO object under the influence of a change bar, an area (with
correct border-style/width/color... settings) has to be created as
an xsl-absolute area and placed as determined by the change bar style
relative to the column or page edge.
For areas generated in the body-region, these additional areas are
children of the flow area, for after/before/start/end they are children
of the respective area region.
If I understand the FOP code right, the areas are actually constructed by
the various layout managers in addAreas().
That is my understanding too.
Now, when creating the change-bar areas, one could for every area thus
constructed, add a change bar area at the correct position in the area tree.
But, it is desireable to merge change bar areas, because many areas
will simply be the same or be adjacent to each other down the page side
and should thus be represented as a single area representing the union
of these areas (as far as possible).
Another point is that the change-bar areas have a "z-Buffer" trait that
decides visibility of overlapping change bars: I am not sure how to handle that
yet.
Desirable yes, but I'm not sure it is essential. I would try to get it
working without merging first and then evaluate if the solution is
acceptable without merging and if so tackle merging as a later project.
We can certainly help with the evaluation if you post into a bugzilla entry.
Would it be best to really add the change bar areas when the originating areas
are constructed and merge on the fly or would it be better to
search for all change bar generating areas when the page is finished and then
to perform the merge?
Currently missing altogether are unit tests for the code I have added
or changed.
In short, we are getting somewhere.
Thanks for the update. It is encouraging.
Chris
