Just a couple of notes on the discussion below.
It is a mistake to say, because there is no great ferment of coding, that nothing is being done on the redesign of layout. I, for one, am currently giving the layout a great deal of thought, triggered in my case by the requirements of integrating the alt.design FO tree. I'm sure the Keiron is in the same boat, as are you, Jeremias and, I think, Jo"rg (my mailer may scramble this).
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. 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.
I don't want to discourage your efforts, but I think you will need to keep these things in mind.
Peter
Victor Mote wrote:
Jeremias Maerki wrote:
I'm slowly getting the impression it may be better if we really totally modularize FOP (splitting it up into several independently usable subprojects) so development is only split in the layout field which is the major problem-child here. But that alone would take long enough and I can't even imagine how much it will hurt the redesign.
...
In short, nothing is being done on redesign now, so how can it possibly be hurt by anything?
...
It would be helpful to resolve some of our high-level control issues before starting down this path, or at least as part of this project. Moving control of when layout is started, when FO trees are destroyed, etc. up to higher-level objects will be extremely helpful in isolating these subsystems from each other and allowing multiple layout strategies.
I see the sequence as follows: 1. Resolve design of, then implement the high-level control changes. This is the Session / Document / Rendering Context issue discussed on the Avalonization wiki, section entitled "Startup Concepts Proposal" at http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization
2. Isolate the (existing redesign) layout by forcing all contact with the layout systems to run through the LayoutStrategy. Every layout class except the Stategy implementation becomes non-public (I think). 3. Drop in the maintenance branch layout as an implementation of LayoutStrategy, keeping it isolated as well. Even if this effort is unsuccessful for some reason, or the redesign layout is completed before this can be done, steps one and two above are still needed & useful.
-- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
