--- Finn Bock <[EMAIL PROTECTED]> wrote: > > The layout dimension that is stored in the FO tree > is constantly updated > during discovery of BreakPoss'es and is never > reused, not even when a > block is split over a break where new values are > assigned. >
I don't know enough to comment too much on which implementation would be better here, but the spec does not appear to have much problem (see [1], also Finn's earlier reference to the spec's conceptual procedure [2]) with back-and-forth processes, updates, etc. between the FO Tree and Area Tree. Indeed, it seems to indicate that this kind of interaction does need to occur for the process to work correctly. Now if would be faster or more efficient to do so, that may be another issue. But Finn's ideas seem to be sufficiently in agreement with the spec. [1] http://marc.theaimsgroup.com/?l=fop-dev&m=107503563018878&w=2 [2] http://marc.theaimsgroup.com/?l=fop-dev&m=107688130007968&w=2 > The solution I propose makes it impossible to run > two different > renderers concurrently, but it does not in any way > prevent the FO tree > from being reused with another renderer after the > first rendering is > finished. > > > This is another argument > > to separate FO tree and layout information. > > No, not really IMO. > I think I agree with Finn on this issue. Reuse of the FOT/AT, i.e., re-rendering from the same input FO, but with a different output type, would probably be only a few percent of all usages of FOP. It is trivial enough that it should not weigh into the architectural decision, especially if doing so would (1) create a messier, hard-to-perfect design, or (2) slow things down for bulk of users not requiring this functionality. Stated another way, if those wanting both PCL and PDF for the same input FO would have to have the FOT & AT regenerated from scratch, we can live with that. For one thing, that's probably the current situation with the commercial renderers anyway. Also, a requirement for the FOT and AT to stay-in-memory and be reenterable may end up resulting in a rather buggy implementation. Glen
