Hi Stephan, Stephan Thesing wrote: > Hello, > > just a short status / question update. > <snip/> > > 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 change-bar. > I appreciate any comments and suggestions! Hoping the above gives you some hints, Vincent
