> -----Original Message-----
> From: Peter B. West [mailto:[EMAIL PROTECTED]

> Thanks Andreas.  Yes, I disagree, but then, so does the spec.  What
> information *should* do is not terribly relevant.  We need to work out
> and express what information *must* do to get this thing working.

Voila! Without worrying too much about "textbook 'should'-stuff"... It is
after all *XSL*-FO, so I guess the basic compliance rule is also for FO
processors: 'the order of the processing events doesn't matter at all, as
long as the produced output is correct.'

> > [Me:]
> > ... Would it really be worth a shot to change the design
> > there, and flip a switch? Throw the FOTree away and just fill up
> > the AT and re-use that?
> Or process the minimal relevant parts of the FO and Area trees in
> parallel.  That is what I am working towards.  I believe that
> page-at-a-time layout with just in time processing of the FOs is
> possible.  Given that, both FOs and Areas can be kept alive while
> required.  (I haven't given any thought to rendering.)

Indeed. When I began thinking about 'borderline-cases', it became clearer
that situations where you need to wait for more than one page to complete
the layout are rather exceptional anyway, so it's most likely the better
option to treat them as what they are: 'an exception to the general
processing flow' (--IOW, not *all* theoretical possibilities implied by the
definitions in the spec should be covered by the *basic* processing

> Note that forward references are always going to be a problem, but that a
> combination of weak/soft/phantom references and serialization should
> keep memory requirements manageable.

That's where your producer-consumer buffers step in, right?

So.. by 'minimal relevant parts' you actually mean something as 'reduced
skeletons of subtrees' that in themselves provide a way to pull the events
generated by their descendants from the buffer, without themselves actually
holding a reference to the descendants, so while the ancestor is being kept
alive, the descendants can be happily collected by our friend GC if no
longer used by another process, while the ancestor remains at our disposal
to re-pull the same events from the buffer if/when they are needed.

Is this close?



Reply via email to