On Thu, 2002-11-21 at 21:14, Victor Mote wrote:
> 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.

I see. That is a different angle than what I was thinking of.

The fo tree knows nothing about the area tree (in theory, some inline
areas are created in the fo tree for convenience at the moment) and the
two are completely separate.
The layout manager is the bridge between these two constructs. The
layout mangers first do the layout and then once the layout is complete,
except page reference, then it adds the areas to the area tree.

So in your scenario with an auto table layout. It does not start
creating and adding areas (to pages 150-4999) until it has reached page
5000 and has worked out the width of the columns.

So yes the area tree is immutably laid out and plays no part in the
layout process. Adding/adjusting and removing areas from the area tree
makes it much more complex and error prone. So the design is that the
area tree is a simple data structure that is created and used by the
renderers. The layout managers only create the area tree.

So the area tree plays its part in allowing for arbitrarily long
documents, by rendering pages as soon as possible, when added to the
area tree or allowing the caching of pages if it cannot render
immediately.

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.

It might not be so obvious in the code but the layout managers work by
first getting breaks in a break position, then once the breaks are
decided it will add the areas that correspond to the breaks. So it is a
two step process that should be considered separately. Obviously adding
areas is dependant on the structure of the break information.


> 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.

As above they are not changeable, the layout manager will change it's
breaks using the information from the fo tree.

> 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.

For live editing I think the situation would be the same. The layout
managers would adjust the layout and then recreate the areas and pages.

> 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.

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.
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.

> 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.

Thats fine.
One of the specific aims was to separate the parts of the code as much
as possible so that anyone could contribute to a particular area without
needing knowledge of everything and running the risk of creating bugs in
some far removed area of the code. Also of course, better processing,
ability to cache etc.





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to