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


> 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

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


Reply via email to