John Austin wrote:
What I infer of the Tree structures in your discussion and Peter's code suggests to me that FOP creates a DOM-ish view of the document in one or more trees. This is a mis-match with the SAX parser that is in there somewhere.
FOP's design on the SAX/DOM issue was a difficult issue for me to grasp, and when I did, I documented it here: http://xml.apache.org/fop/design/parsing.html#input
There is no mismatch at all. The input we work with is a tree. Therefore a tree-like structure is absolutely necessary to represent it. I am pretty sure from past discussions with Peter that he employs a tree-like structure as part of this pull-parsing. So, if it is important for FOP to use a tree-like structure to represent its input, the only issue is whether to use DOM or some home-grown structure. Since a home-grown structure is much lighter and more flexible for our needs (AFAIK, adding business logic to a DOM would be impossible), the only question is what standard way should the home-grown structure be built. SAX provides a much lighter-weight way of building our home-grown structure than anything else that I have seen.
Even the dreaded pull-parser uses SAX.
Now, if you can figure out how to digest an FO document without building a tree that represents a page-sequence object, I hope you'll share it with the rest of us. That could be a breakthrough indeed.
The problem is the same one that FOP has always struggled with - how to 1) discard subtrees in a timely manner, and 2) serialize subtrees for efficient caching and retrieval when they will be needed at some time in the future.
Peter -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
