Keiron Liddle wrote: > Now it is true that it is only part of the solution. To allow for the > important ability to do arbitrarily long documents it will also need to > handle the fo tree and layout manager information so that it can be > cached or kept minimal.
This is where I thought Peter's posting was useful. I had been musing about using a database to store big chunks of trees when they are too big for memory, and the author he quoted pointed out a more tree-specific idea of how to do this. I think I see how we can add something like this down the road to our existing design. One of my concerns (that the FO tree data didn't persist long enough) was a misconception on my part. > > You are correct for the current use-case. I have jumped a bit > past that into > > trying to make room for other use-cases that might require the fo to be > > changed and serialized (the WYSIWIG). Setting that issue aside for the > > moment, let me rephrase the question, because this is really > the huge big > > issue that makes me uneasy with SAX. Don't we need random > access to the fo > > tree for the current page sequence? > > * If so, then, using SAX, don't we have to duplicate that same > > information in the area tree to be able to handle rebuilding > > 4850 pages? > > That is true, the information must be somewhere for it to correctly do > the 4850 pages and I can't say that I really have an anwser to where it > should be except not in the area tree. I have been working under the presumption that the correct place for that data to live is in the FO tree, but also thought the FO tree was not really being built in a persistent way. So, if it is being built & used that way, then my concerns were ill-founded, and I agree that that we are OK here. I agree that it should not be in the area tree -- it was my fear that it was. > I think tieing the area tree to the fo tree would make it much more > difficult to do the caching and releasing old fo tree data. > The information in the area tree is often fundamentally different from > the fo tree. > > I see the merit in the FrameMaker way of doing things but I think that > would make things too complicated at the moment. Fair enough -- my only concern at the moment is making sure that our design is robust enough to handle this in the future, if we decide to do something like that. The big advantage is that if you wanted to serialize the document, your area trea "view" gets serialized along with the structural data (pretty efficiently, since the area tree view is basically a list of pointers into the other data), & your layout work persists from one session to another. > If that does turn out to be a possiblity then what about this: The area > tree stays as it is, a structure to be used by the renderers. The areas > are subclassed to hook up with the fo tree and layout and it will behave > as a normal area tree when rendering. The layout can add/remove/adjust > areas in the subclassed area tree. That sounds about right. OK, I think I follow what is going on enough to efficiently start looking at code, and I am satisfied for the moment that our design is flexible enough to get us where we want to go. Thanks for the tutorial. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
