Peter B. West wrote: > While I don't denigrate any of these ongoing efforts, I am increasingly > of the view that everything occurring between the reading of the fo xml > and the layout of the area tree is interconnected in very nasty and > intricate ways. The description of this process in the Rec (I resisted > the obvious temptation here) has done many developers, including the FOP > developers, a great disservice. > > It's this intertwining that makes me skeptical about pluggable layout. > It may be feasible, but I don't see that it is feasible until we have a > very good understanding of the way layout will be achieved, and a full > picture of the flow of control in the first full implementation.
My naive understanding of the Area Tree is that it could / should be constructed as a "view" of the FO tree. It should not, for example, IMO, contain any Strings at all, but objects in it should contain offset and size values for the parent FOText object in the FO tree. Similarly, perhaps it should not contain the trait values at all, but should compute them from the parent on-the-fly. The FO tree should normalize the values as much as possible (which in many cases is completely), then the Area tree can complete whatever computation is necessary before returning the value to use. I realize that this violates your compute-it-once principle, but I was frankly confused by that principle. It seemed to me that the intertwining issues that you mention utterly prevent compute-it-once. Second, and more importantly, regardless of what design is used in the Area Tree, there is nothing that prevents us from factoring code that is common to more than one LayoutStrategy into a module that is usable by any LayoutStrategy. If there are issues that force things to be intertwined, then those could be "common" code. > Factoring out the high-level control is still a valuable and achievable > step forward, but I'm not sure about "control of when layout is started, > when FO trees are destroyed." I assume that refers to the patient vs. > eager layout discussion. At that level, certainly, control values can > be factored out. Actually the two examples listed are, in my mind, examples of the high-level control issues that we want factored out. Patient vs. eager is only part of the story. Also included here are such issues as reusing session and document objects in embedded environments. > I don't want to discourage your efforts, but I think you will need to > keep these things in mind. I will. Thanks. If I come back humbled from the effort, perhaps at least some useful documentation will emerge. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]