> -----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 framework). > 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? Cheers, Andreas
