Peter B. West wrote:As I imagined.
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.
Yes, in that sense.
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.
If we are both correct in assuming that layout is still triggered by the end of a page-sequence, 2) above is reinforced.
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.
I have no objection in principle to such a solution.
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.
That's news to me, Victor.
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."
No. I'm saying that the natural, clean, *good* (as in 'quality') way is to do layout in parallel with FO Tree building. I'm sure there is a myriad of solutions. They just aren't as nice, in the nice sense of the word.
Again, that's news to me. I've repeated my reasons on many occasions. It boils down to this: there are properties which cannot be resolved without reference to an area created by an ancestor FO node of the one on which the properties are defined. You say, "Mark it as unresolved, and do it later," with no idea of the implementation implications of that statement. I wrote an implementation of properties from the Recommendation up, with the *same* approach, and when I got to the end, realized it was crap, as I seem to recall saying once or twice before. Now I want that area available to me (whether I know its dimensions or not) when I parse the expressions.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.
That is the essential difference. I have a pretty detailed idea of the implementation of properties, based on that experience.
There are open questions about this. If I don't answer them, it's not that I REFUSE to, but that I don't yet know the answer. I have been out of the loop for about 6 months of this year, but in the other 5, whenever I have been thinking about FOP design issues, I have been thinking about the relationship between FO nodes and areas, and the dynamics of layout. I haven't worked it out yet. When I do, this list will be first to know.
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.
Please explain this part again.
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.
Areas *are* about layout. Working out the relationship between FO tree nodes and areas implies working out the structure of layout, for me. Before I can draw meaningful conclusions about former, I need to have determined the latter. This, again, is my requirement for my design decisions, based on my usual bad design principles.
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).
Page aren't necessarily spat out too quickly, in the sense that a layout may not be regarded as final until higher level decisions about multi-page issues are made. But in my current thinking, layout is attacked on a page basis, rather than on a page-sequence basis.
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.
Threads get stale. Other things happen. New people arrive. The entrance of John and Finn has triggered a lot of discussion about alt.design property handling, so the context of discussion does change over time. I have, as I said, been racking my brains over these issues for some time now. Difficult issues take me a lot of time to resolve. This is what I meant earlier by the slowness of my understanding.
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).
alt.design was started as an experiment in the representation of properties. I expected that by the time I was finished, the layout redesign would have been hashed out in great detail. I couldn't follow the process, so I got busy with properties, and a general idea of how to structure the parsing, FO tree and Area tree builders. What progress has been made on the design of layout in HEAD over that period?
In the past 12 months, I have had at least five developers approach me off-line, wanting to get involved in alt.design. I had to turn them away, because I had the huge issues of layout design in front of me, and nothing definite to give them. They must all have been monitoring fop-dev. I didn't see them getting involved in HEAD.
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.
Victor, please.
I guess I'll do that when I see that it is, on balance, superior.
Do I ask anything else?
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 no objection to using LayoutStrategy if it meets alt.design's needs. I have had other fish to fry, so I haven't had a chance to investigate it.
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.
So I guess it must be my fault that FOP design issues have not been resolved and documented in full over the past three years that I have been involved. I'm not the Messiah, I'm a very naughty boy.
I realize the tone of this posting has not been entirely irenic. I'll try harder.
Peter -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
