Hi Stephan, Stephan Thesing wrote: > Hello, > <snip/> >>> 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.
This doesn’t exactly happen like this, although that doesn’t change much of what you would have to do. FOP implements a total-fit algorithm. Basically, instead of creating one page at a time, it optimises the layout over the whole page sequence. It does so by playing with elastic spaces between blocks in order to homogenise pages. Suppose that a big unbreakable block doesn’t fit on page 10 and must be deferred to page 11. By slightly increasing vertical spaces between earlier blocks, content can progressively be shifted to the following page until page 10 is reached, and fill up that latter instead of leaving it half empty. So the actual layout of page 1 may actually not be known until the very end of the page sequence has been reached. I must actually refine my concern above: at the moment, a two-pass process would degrade performance only if a change-bar encompasses several page sequences, which I guess would rarely happen. Still, if later on we want to implement a lower quality, lower resource demanding layout process, we wouldn’t want such a two-pass process. <snip/> > 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. If you don’t need change bars for RTF output, then don’t worry about it. If that were depending only on me the RTF backend would have been deprecated long time ago :-) It doesn’t fit well in the rest of FOP and anyway is no longer so much useful now that ODF, among others, is around. Vincent
