Keiron Liddle wrote:
On Thu, 2002-12-05 at 13:01, Peter B. West wrote:There is an implication in what you are saying that you do have the direction forward for the FO processor "internalised", so to speak,
and that a complete FO processor is, as Christian says, just a matter of time. I, and I suspect Arved, wonder why that is not clear to
everyone. You have a great track record in FOP over a long period, and if you insist that the redesign is moving towards completion, I would be inclined to believe you, but I do need to be shown how. Arved also
has a great track record over many years in FOP, and Arved seems to be skeptical.
Please define "redesign". The following things are at least better than anywhere else: area tree, image handling, pdf lib, svg, renderer. Fo tree is better than the maintanence branch.
See comments below.
If you are referring to the layout then I can't say that it is anywhere near completion, but in general it is currently better than the maintanence branch. (lack of a number of features and missing words aside) It seems to me that a lot of the arguments are of this type: http://www.intrepidsoftware.com/fallacy/straw.htm As far as I am concerned it is largely irrelevant whether the particular layout design is 100% correct. Yes it is extermely important and will be best tackled by breaking it down into smaller problems. But so far I have only heard arguments against two methods in the layout managers, getting breaks and reset. Sure it probably would be helpful to design a layout algorithm isolated from all the other stuff and that is something that someone could pursue.
Keiron,Believe me, I can find plenty of other things to do that have no relation to the layout. Still, from my perspective it is a high priority to get it to a level similar to the maintanence branch, this will make fixing bugs, responding to users, integration with other projects documentation etc. a lot easier. Then to move forward from there.In any case, I would like to be able to make useful suggestions concerning the redesign. I have many times in the past expressed the genuine hope for the success of FOP by whatever path, and I had never, until recently, even suggested that anyone commit to alt.design over the HEAD redesign. I cannot, however, commit to a design that I either do not understand, or do not have any confidence in. Who can?If all you care about is a perfect layout then that is reasonable, then reduce the problem/difference to the layout. Most users care more about lots of other issues. Catering for these users will help us IMHO.
We seem to have achieved considerable agreement here. From what you say above, the HEAD redesign is nearing the point at which it can take over from the maint branch as the usable version of FOP. That solves one of the problems that Karen mentioned, and will integrate the efforts of those with production commitments, and those working on the New Design.
You say, above:
> Sure it probably would be helpful to design a layout algorithm isolated
> from all the other stuff and that is something that someone could
I'll put my hand up for this. It is my intention to scavenge as much code as possible from HEAD to implement the design. It may not come to that. If those working on HEAD adopt elements of alt.design as they see the possibilty and benefit of so doing, the incremental design approach you favour and alt.design may turn out to be synergistic.
In any case, I hope to pursue these goals without feeling a pariah in the FOP development community, when my purpose is a better FOP.
I hope this goal remains relevant across Sun's pending announcement.
Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]