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

It seems to me that a lot of the arguments are of this type:

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

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 over
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
> pursue.

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 as they see the possibilty and benefit of so doing, the incremental design approach you favour and 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.

"Lord, to whom shall we go?"

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to