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

yes, this would be merging of the generated areas, which should be easy
> > 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.

I don't pretend to really understand the layout in FOP yet, but my basic
understanding was:
 - As soon as a page-sequence has been parsed, it is layouted, the 
     layout managers are created.
 - When a page has been filled (approx), little adaptations are done, 
     the area tree for that page is complete and can be rendered.

Here, as soon as the page has been really created, one can add the change bar 
areas to it and render it.

The general problem with the change bars is that they don't create any
areas in themselves but rather add a property to each fo element between
the begin and end marker.  That property being that a change bar should
accompany the element.
Thus, they are initially an element related property.

If such an influenced element creates several areas when being layouted,
all areas have to be accompanied by change bars.

Thus, we have to wait, until the areas of the influenced elements have been 
created, which (my understanding) is when a page layout has been finished (the 
page created with the areas on it).
Only then can we know the vertical positions of the areas, which are needed for 
the change bar areas.

I may be missing something here:-)

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

I have to look into that:-)

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

Thanks for your comments!

BTW, as far as I understand FOP, the area tree is never used for RTF output, 
but rather the event mechanism is used, that notifies the RTF backend for 
start/end of fo elements, which are then directly transfered into RTF.
Thus, the change bar stuff tied to the areas will not work for RTF and
extra code has to be added to the RTF backend to handle the change bars.

Best regards...
Dr.-Ing. Stephan Thesing
Elektrastr. 50
81925 München

Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

Reply via email to