Peter B. West wrote: > >>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. > > > If we are both correct in assuming that layout is still triggered by the > end of a page-sequence, 2) above is reinforced.
I guess you are saying that a page-sequence will use too much memory (??). Again, this is a non-issue. Just use a different LayoutStrategy that is more eager. > > 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. Well, here are the threads: http://marc.theaimsgroup.com/?l=fop-dev&m=105817834112610&w=2 http://marc.theaimsgroup.com/?l=fop-dev&m=107074009107318&w=2 > > 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. OK, we can agree to disagree on this. The only cost is that you'll have to use your own FO-tree-like-thing, which IIUC, you already have. > > 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. > > > 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 Actually, I think I do have a pretty good idea what the implementation implications of that statement are. Very simply, if the "get" method is run, and the relevant Area hasn't been passed, and I need it to resolve the value, I have to return an "I don't know" value. That means that there is a logic problem in the layout that needs to be fixed, i.e. the Area should be created before this request is made. None of this implies that layout must be run in parallel with FO Tree building. > 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. OK. The question I keep asking is "why"? What is wrong with deferring property resolution until after parsing? You say that I don't understand the implementation issues. Well, in plain English, what are they? And you still haven't addressed the fact that you can have items that are grafted into multiple places on the FO Tree. > 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. I wasn't trying to force you to come up with a solution. I was asking you to evaluate a proposed one. I am trying to find a simple, robust way to deal with the problem, which does not require concurrent parsing and layout, and am asking you to evaluate it. I did that out of respect for your experience here. But your answers come back "you don't understand", "my first implementation was wrong", "parsing and layout must be concurrent". These are all non-responsive. You seem to be prejudiced against any idea that might allow parsing and layout to be separated. > >>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. What I proposed is that the "get" method be passed the relevant Area. This can be null, but if "get" can't compute the value without the Area, then "get" must return an "I can't compute that" value. > >>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. Well, the fundamental disagreement is whether properties must be totally resolved at parse time. All of the rest of your logic depends on that, and that is why you have gone down the path that you have, all of which seems needlessly complex to me. I acknowledge that I may have oversimplified the problem. If so, having you tell me so is not nearly as helpful as telling me why. > > 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. Threads get stale when people don't answer. New people haven't changed the need for sound design. Even when I point out the fact that you haven't answered the previous threads, you still don't answer them. The context has not changed even slightly. Difficult issues may take time, but they actually take forever when they are just dropped in mid-thread. You may be interested to know that I have spent a lot of time thinking about possible solutions to this problem also. My purpose here was to maximize the value of your experience, and to salvage as much as possible from the work you have done on alt-design. I see now that you are not willing to do that. I'm sorry. It seems to me to be a net loss for both you and the project. I'll test my ideas another way. > > 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? See, I have been under the mistaken impression that we were on the same team, that your efforts were eventually intended to benefit the FOP project. I did not understand that this was a contest. If you have forked the project, then let's set up a separate mailing list for alt-design, so that I'm not distracting you and you're not distracting me. For the record, IMO FOP has some infrastructure problems that have brought layout work to nearly a halt. My work has been aimed at trying to resolve those problems. I am looking forward to working on layout, but some days you have to do the dirty work before you can do the fun stuff. One of the infrastructure problems that I have been trying to solve is alt-design. I do not mean to imply that its contents are a problem. However, its existence means that we have at least one unresolved design issue. Either trunk or alt-design is a superior design. I have made pretty substantial efforts toward resolving this question for may own satisfaction, and have concluded that the trunk is superior in general, the properties handling being an exception. So every time I see an alt-design post, or a new developer being recruited to that line of thinking, I think to myself "wouldn't it be good if we could resolve this design issue, come to an agreement, and get everyone on the same page?" If all of the developers are equal to 100 units of progress, and 20 units break off to do something else, we are down to 80. If those 20 are pulling against us (which is true of alt-design IMO), then we are down to 60. I must admit that it sounds pretty lame for the 20 to ask why the whole is only working at 60% efficiency. So, one must ask whether the 20 are correct, whether their design is better. OK, if so, explain or show how. I understand you to be unable to explain how, but still hopeful of showing how. That prospect seems dubious. I have never written a line of code that wasn't predicated on an idea that it would work. OK, so I will write off the 20 that isn't pulling with us. What I am going to put a stop to is the 20 pulling against us. At the point in time that you are willing to explain or show why the alt-design is better, I'll be glad to listen. In the meantime, please forgive me for ignoring it entirely. And I will stop trying to reconcile the two. My attempts to bring unity here have badly backfired. I apologize to all. > 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. Yes, this is the 20 pulling against us. New developers are needlessly forced to choose sides. Most want to code, not get involved in political disputes. I'll go so far as to suggest that the negative effect may be much greater than 20 when this is considered. > > 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 you are disagreeing with my point. You don't have to use the trunk FO Tree or LayoutStrategies. That leaves Area Tree and Rendering. If you don't want to use those, then I think you really have a separate product. Your persistence on the matter can only be interpreted as thinking that HEAD should adopt your approach. > > I guess I'll do that when I see that > > it is, on balance, superior. > > Do I ask anything else? Yes, see above. > > 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. No hurry. In the meantime, it will be a net benefit to the project for you to cease and desist from denigrating FOP's design in favor of another whose benefits cannot be explained. > 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. Well, I won't blame you for all of them, or for not being the Messiah, but I think it is very fair to hold you accountable for the agitation on the issue at hand. And, as you well know, this is a big issue. The resolution of smaller downstream issues rely on the resolution of the bigger upstream issues. IMO you owe the project one of the following: 1) to throw in with the trunk design, 2) to explain in logical, supportable terms why your design is better, or 3) to expect the rest of us to ignore it. > I realize the tone of this posting has not been entirely irenic. I'll > try harder. And I apologize for my part in this desultory conversation. If anyone thinks I am out of line here, I'll be happy to find something more productive to do with my time. Victor Mote
