Hi Stephan,

Stephan Thesing wrote:
> Hello,
> just a short status / question update.
> 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.

The area tree described in the Recommendation is non-normative,
therefore we are free to deviate from it as long as the final visual
result is the same.

And I’m actually not keen on the idea of generating a change-bar area
for /each/ area under the influence of a change bar. This will give many
overlapping areas (for example an fo:block produces a normal area, plus
possibly a line-area, which will itself contain many inline areas. If
a change-bar area must be generated for each of them...). The visual
result is likely to look non-continuous, as the borders of a table for
which we have already had complaints. Ideally a single area would be
generated on each column.

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

It all depends on how this is implemented, therefore I’m awaiting your
patch. But that seems to imply a two-pass process that I’m not sure we
want. Imagine a change-bar that starts on page 2 and ends on page 50. We
don’t want to wait that the areas for page 50 have been created to add
the change-bar areas on page 2.

> Can this be realizes in such a way in FOP?

To be honest I don’t have a precise idea of how to implement that in
FOP. But maybe that could be done using some kind of listener. An event
would be generated when a change-bar-begin is encountered. It would be
handled by ‘the proper LayoutManager’ that would record the current
offset from the top of the applicable reference-area. Once the
‘change-bar-end’, ‘bottom-of-column’ or ‘end-of-document’ event occurs,
it creates the change-bar area.

Where should that code be put? Good question... PageBreaker maybe,
although StaticContentLM must also do something.

Moreover, change-bar areas must also be produced for out-of-line areas
like footnotes, returned by objects that are under the influence of the

> I appreciate any comments and suggestions!

Hoping the above gives you some hints,

Reply via email to