Here is what I understand, others may have more to

I see two ways to interpret your question:  (1) what
happens in the code that makes page-sequence be the
lowest granularity we have, and (2) why we do it that

1) When the page-sequence's children
(layout-master-set, declarations?, flow) have been
finished processing, endElement() in our SAXHandler
FOTreeBuilder is called. [1]  That method calls end()
of the PageSequenceObject [2], which in turn calls
endPageSequence() [3] of the FOInputHandler object,
which is either FOTreeHandler for PDF/PS, etc. or
MIFHandler or RTFHandler.

It is endPageSequence() which calls
formatPageSequence(pageSequence, areaTree)--which
starts the formatting process.




2) Our processing is directly on top of SAX--we react
at the start and end of XML elements as they come in. 
Unlike FAD we don't cache into any intermediate data
structures, so I don't see how we could do a lower
granularity.  We could stop at the end of fo:flow, but
that is only one element away from fo:page-sequence's
object endElement() being called from above, so 
nothing measurable would be gained.  

I guess the answer to your question in (2) is (a) that
our process is driven by fo:objects, not the areas
that they generate, and there is no fo:object that
corresponds to "1 page", etc.--that's determined by
fo:flow as it is formatted and (b) there are some
programmatic conveniences to stopping at the
page-sequence level, as the layout-master-set can be
read in one time and is valid for all the pages


--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
> Fop-devs,
> It occurs to me that some of the implications of the
> FAD approach have 
> not been successfully communicated.  Part of this
> may well be because of 
> my own inadequate understanding of the FOP process. 
> Before I continuing 
> with this discussion, I had better ensure that my
> understanding of one 
> important point is correct.  Why does FOP process in
> minimum units of a 
> page-sequence?
> Peter
> -- 
> Peter B. West
> <>

Reply via email to