Peter B. West wrote: > Herewith some notes on the tortured relationship between the two. As I > don't know much about layout in HEAD, I am hoping that differences and > (hopefully) correspondences between my ideas and the HEAD redesign can > be pointed out by wiser HEADs than mine.
I don't claim to be in that category, but hope to be heard anyway. > As I recall, in the original original version, the complete FO tree was > built before the Area tree construction was started. When Mark > Lillywhite looked at the code, his most important contribution was to > realize that the FO tree could be broken up into page-sequences, and the > construction of the page-sequence Area subtree could be commenced at the > end of each page-sequence. This is still true. > In my original design, I intended to run parsing, FO tree building and > Area tree building in parallel, linked together by producer/consumer > buffers. I've done that for parsing and FO tree building, but my > concepts of how to link FO tree and Area tree have been in a state of > flux for some time. Both maintenance and trunk have parsing and FO Tree building integrated. Neither of them nor alt-design have Area Tree building (aka Layout) integrated. So really they both come out at the same place AFAICT. > It seems to me, however, that the key to 1) solving the layout > dependencies of FO property expressions, and 2) reducing footprint, > particularly for those long documents which are naturally expressed with > very large fo:flow trees in a few page-sequences, is to have the areas > generated by the FOs as soon as the FOs are parsed and entered into the > FO tree. Well, some are concerned about memory requirements, some are more concerned about speed, others still are more concerned about quality. Hence the introduction of the LayoutStrategy concept, which can accommodate the scheme that you have suggested here without locking everyone into it. You have repeatedly REFUSED to answer pretty basic questions that I have asked about how to resolve the dependencies between FO Tree and Area Tree. I guess I must settle for your answer above, which I paraphrase as follows: "Unless you are willing to do layout in parallel with FO Tree building, you can't resolve the FO Tree's dependencies on the Area Tree." I disagree. I may be wrong, I may even be very wrong, but why must my pleas for an explanation from you be ignored? You are asking us to make a major, major design change, but you REFUSE to tell us why it is necessary. > If this were done, then there would *always* exist a reference area for > the percentage expressions, even if that area could not always be > dimensioned. Having a reference for the expression makes it > straightforward to resolve the expression as soon as the referent is > dimensioned, and also makes feasible the re-dimensioning of the > referring areas if the referent is required to change (e.g., by virtue > of being forced onto a new page with different margins.) AFAICT, this is the same effect as what I proposed. > Some of my other preoccupations I have mentioned before. Line-areas > should be filled from the bottom-up, while dimensions filter down from > the top. E.g. my procedure for resolving footnotes implies that > individual line-areas are passed up to the page level (region-body, at > least) along with any impacts (footnotes, before-floats) associated with > the line area. When side-floats occur, the line, and its impact (which > is, I think, the entire side-float, which must therefore be resolved > when encountered) are passed back to the ancestor reference area. > > My focus in this is on the *page*-area-tree, which establishes a subtree > of containers. These containers are then filled from the bottom up by > line-areas, themselves filled from the bottom up by the atoms of the > flow. While the page-area-tree is structured, and dimension issues can > be resolved within it, there remains a close connection with the > corresponding FO subtree, which itself is a subtree of the fo:flow > subtree. Both the page-area-tree and the flow subtree can be very > complex. Think of multi-column layout including tables with footnotes, > and a list or two thrown in for good measure. > > The containers of the page-area-subtree are filled from bottom-level FO > nodes. The bottom-level FO nodes must be able to sensibly construct > line-areas, including all of the line-breaking logic that is required. These are all layout issues. You now have the ability to create and use your own LayoutStrategy. > They know nothing of pages, however. When the page-area-tree fills, a > page is ready for rendering or intermediate storage, so the > page-area-tree "goes-away". That leaves the flow subtree in a suspended > state, with the low-level FO nodes demanding space for the next > line-area. (Note that blocks aren't "broken" - instead, areas are > filled until a line-area comes along which would cause overflow. The > offending line-area and its components are conceptually pushed back for > reprocessing on the next page. It is this pushed-back line-area which > generates the initial demand for more space.) This is currently handled through the area.AreaTreeModel concept, which is pretty cool, except that I need to get the LayoutStrategy involved with choosing which model to use. (Some LayoutStrategies by definition don't want to spit out pages too quickly, which is what you have proposed). > This demand percolates up through the flow active ancestry until it > results in a demand for a new page. The page factory associated with > the page-sequence and the layout-master-set through the page-sequence > master-reference, generates a new page container set, and the relevant > area and its dimensions are passed to the flow FO. From here the > container availability percolates back down the active flow descendants, > with the FO nodes generating new sub-areas, and attaching percentage > expressions to their reference areas as control descends. At the > bottom, the line-area generators are given new dimensions to deal with, > and the bottom-up filling process begins again. > > I want to diagram this, and look more closely at the nasty cases as I > do, but comments are, as always welcome. Victor will be upset, I know, > but I can't see the separation of FO tree building and Area tree > building. Keiron may be screaming, "That's what I was doing," in which > case my apologies. OK, I am upset, but not for the reason that you think. Rather than answering the thread that we already had active on this topic, you have chosen to start a new one. This is now at least the third time you and I have been down this path. I don't know the history behind why alt.design is on a separate branch, but these issues were probably hashed out back then as well (before my time). Much of the work I have done over the past six months has been, consistent with good design principles, to make it easier to accommodate your layout ideas, including doing your own FO-Tree-like thing, without rewriting all of the rest of the code. (Don't get me wrong -- your code is not the *only* reason I have made these changes, but it has been a big part of the thinking). The trunk code is now flexible enough for you to drop in your code as a LayoutStrategy. What galls me is that you insist that everyone else must adopt your approach as well. I guess I'll do that when I see that it is, on balance, superior. You won't give me any theoretical ideas why that should be, and AFAICT, there is no practical evidence that it is superior either. (I am talking about FOTree/AreaTree here, not your properties handling, which has been recognized for some time as having some merit). Until you are ready to prove the superiority of your design, my humble suggestion is that you drop it in as a LayoutStrategy, and keep working on it. This makes the most upstream common code that you use the AreaTree itself. I have stated before that our multiple lines of development are our biggest problem. I was wrong. As bad as that is, the constant agitation of design issues that should be resolved and documented is even worse. Design by committee is a horrible idea anyway, but when people ignore critical threads and continue beating the drums anyway, it is downright unbearable. Victor Mote
