Keiron Liddle wrote:
> On Thu, 2002-11-21 at 12:43, Victor Mote wrote:
> > To conclude, if I were designing this system from scratch,
> based on what I
> > know right now, I would:
> > 1. Use DOM for both the fo tree & the area tree.
>
> I don't know whether I would call it a DOM but the area tree is an
> independant data structure that contains all the information necessary
> to render the document.
>
>
> > 2. Write them to disk when necessary, hiding all of this from the layout
> > managers.
>
> This has already been done for the area tree. I use the
> CachedRenderPagesModel all the time. If it cannot render the page
> immediately then it saves it to disk. The layout managers only know
> about adding areas to a page and then adding the page to the area tree.
> For rendering it can dispose of the page once rendered, for awt viewer
> it could save all pages to disk and load when necessary.
>
> As described here (written a long time ago and needs updating):
> http://xml.apache.org/fop/design/areas.html
OK, I just went back & reread it. There is still something I don't
understand & I'll get to that in a minute. First, let me say that perhaps
the better way for me to learn this would be to follow it in a debugger. I'm
not too lazy to do that, and if /these issues/ are working pretty well right
now, then that is probably what I should be doing -- just say the word.
Here is what (after reading the doc & considering your comments) my thick
head doesn't yet grasp -- when we say the page is "cached", I understood
that to mean that it is immutably laid out, but that it can't be rendered
yet because some previous page cannot be finally laid out yet. What I am
trying to address is the situation, like the auto table layout, where
something I see while trying to lay out page 5000 changes pages 150-4999 as
well. I have to now push some rows or lines from 150 to 151, which triggers
pushing some lines from 151 to 152, etc. So the first question is whether
the cached pages are changeable or unchangeable. If changeable, then we
should be able to deal with arbitrarily long documents and (assuming some
reasonable amount of basic memory) not worry about running out of memory --
constrained only by disk space.
The second question that I am trying to grasp is, if the cached pages are
changeable, then how do we know enough to change those 4850 pages properly
without having our fo tree at hand unless we duplicate the information from
the fo tree in the area tree.
> I don't see why you would need all the fo tree available, each page
> sequence is independant for the flow and often each page can be finished
> before the next page.
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?
* If not, then, in a big-picture way, how do we go about
rebuilding 4850 pages?
> > 3. Use an event-based layout mechanism so that the fo tree
> doesn't even have
> > to be there to get layout work done.
>
> Depends exactly what you mean but I think that is the general idea, care
> to implement it.
OK, I see where I was not clear. In my mind, if there is no fo tree to tie
the pieces of the area tree to, you basically have to build one. This is why
I brought up Word & FrameMaker -- their object models keep the organization
of the document (analagous to our fo tree) intact. My theory is that we
eventually hurt ourselves by trying to avoid this. The difference is that
they have to serialize that organization, and we don't, at least for our
current use case. However, perhaps because I am still confused about our
general strategy for dealing with the ripple-effect of downstream changes,
their model seems to be a good one. I am envisioning an area tree that
contains no text at all, but whose objects merely point to nodes & offsets &
sizes in the fo tree. So, for example Line object l contains an array of
LineSegment objects, one of whose contents comes from an FOText node,
starting at offset 16, size 22. Not only is my text there, but so is most of
my font and formatting information. What I have is two different views of
the same data -- one that is more structural and the other the specific
layout. I have no problem (in our current use-case) with throwing away
page-sequences from the fo tree and area tree to free up memory as we go.
> Does or could
> > the new design give us the ability to (with say, a configuration option)
> > choose between Layout Philosophy A and B? By this I mean 2 (or
> more) layout
> > packages coexisting in the same code base, and sharing common
> resources that
> > can be selected (configurable perhaps). If so, then we can play
...
> This should be quite simple to do.
> There would be a basic interface set for the layout managers when being
> created by the fo tree. We could possible have a common one for inline
> objects.
> The actual layout implementation could then be changed.
>
> Again, this will need to be implemented.
That is very good. And I know from other threads that we owe this to the
redesign. This basically puts the onus on anyone who wants a different
design to "just do it". Don't break the other model, but drop an additional
one in.
> I keep getting the feeling that everyone is saying the current design is
> wrong and here is a better idea, which turns out to be the same as the
> current design.
I don't think there is any lack of respect for you or the design here, but
merely ignorance on my part -- in other words, we have a documentation
problem that I will try to address after I grasp the issue better. I get the
feeling that 3 or 4 people at most understand the design well enough to
"defend" it for us barbarians to whom it seems counter-intuitive and
awkward, or unnecessarily limits our flexibility. I get the feeling that
everyone is eager to help -- we just want to make sure we are on the right
track.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
