Victor and fopdevs,

See below...

Victor Mote wrote:
Peter B. West wrote:

I'm pleased and surprised to hear that most of your design questions
have been answered.  What scope of design are you talking about?

Ah, a good question. The scope of design on which I am currently working is:
1) refactor the startup procedures (Driver) into Session, Document,
RenderContext, and RenderTask objects for greater reusability of each of
those items.
2) refactor the redesign layout into a component that can very easily be
replaced by some other layout engine.

This is a very nasty one. The maintenance and the HEAD code may encourage you to believe that it is not. What I am looking to do next with is to make the resolution of FO nodes occur in the context of the Area into which the FO node is being composed. I.e., to intimately link FO tree and Area tree construction. I am intending to do this because I believe it is the only comprehensive and clean solution to the problem.

3) drop the old (maintenance branch) engine into the redesign code, if
possible, using the same concept described in #2 above.

You are correct that not all of my layout design questions have been
answered. However, I am convinced that completing the above work is the
quickest way to getting those questions answered, because it will get our
common code base components (those other than layout) common again, and get
layout to the place where we can have more than one option. It will take me
a while to get through this big-picture work before I can start on layout

I am a little more disturbed to hear that is once again my
baby.  I have been posting here intermittently over the past few weeks
with design notes that explore the implications of my discoveries about
the impact of some particulares of the Rec on my current properties
handling, the implications for the layout of those issues and the
integration of, and some general questions of layout design.

Here is my frank take on the work: I /think/ you are on the right
track as far as properties go. In a general way I understand the problems
you have described about actual layout placement driving some of the
property creation. I am inclined to think that these problems can be solved
in layout itself rather than trying to make layout drive the FO tree

See above.

  However, I may be wrong, and at some point (not today) I may try
to get better up to speed on this issue. I am not very excited at all about
the pull parsing concept. It took me a while, but I finally got generally
comfortable with the way our parsing now works, and went to the trouble of
documenting why in our developer doc, with the hope that we can reach
consensus around it, and prevent future new developers from stumbling there.

I have made some comments about "the way our parsing now works" in another post.

The reason I have not jumped into the work is that I do not see it as /the/ most important place to spend my efforts. That does not mean that it is not important, just that it is not as high on my priority list as it is on yours.

With that said, I am eager to see the working code from your efforts (even
the ones that I am inclined to disagree with), and to hear how they will
benefit the project. Until there are pieces of that are ready to
be merged into the trunk, it all seems like speculation.

Agreed, which is why I a going to follow through on the implications of the Rec rather than try to integrate a model of FO tree parsing and construction which I know to be flawed.

 And rest assured
that I will reserve judgment about all of it until that time -- I kick
myself about 10 times a day as I discover things that I think I should have
known before.


I freely admit that I have not yet grasped why layout should affect properties. I understand that marker properties need to be resolved at layout time, but it seems like the property in the FO tree then becomes the integer equivalent of "to be resolved".

Marker processing is a clear example of the serendipitous advantages of pull parsing. It is the pull parsing design that makes the resolution of markers in static-content a near-trivial exercise. If you refer back to the diagrams I posted about marker processing, you will see that streams of FoXMLEvents are being buffered in two places. If the input buffer is a parameter, the normal FO tree building processes can be invoked on such buffers, which can also be dynamically switched to include the marker subtrees from earlier fo:marker processing.

All of this may simply be because my comments are not considered
relevant.  Nonetheless, I believe that the *kind* of design commentary I
am making is of great value in the development of the design of layout.
irrespective of the particulars of my work.  One of the problems of
getting more people involved in the redesign work is the opacity of the
process.  It seems to me that the redesign documentation is, to too
great an extent, simply the code.  I say this in spite of the other
documentation that has been done.

Your comments are relevant. However, I frankly see issues like pull parsing
to be a net distraction to the project, so I admit that I don't pay much
attention to them. However, I think it is a worthy goal for the project to
eventually resolve alt-design one way or another, and since you seem
somewhat determined to bring the issue to a head, perhaps now is a good
time. If you will present your ideas in the form of a proposal(s) to be
voted on, I assure you that I will spend whatever time it takes to get up to
speed on the issue before voting.

The only issue I wish to bring to a head here is the attitude of existing committers to new potential committers who want to work on

There are design issues here which a vote of the existing committers will not solve. Two years ago I decided that what is now the maint branch was not going to solve the FOP problem. Sure, I had no experience in Java or XML, and I found the code unspeakably obscure. However, I was not the only one who thought that a comprehensive redesign and rewrite was required. The committers decided against that. That was around two years ago. In the interim I have rewritten the parsing and FO tree building, and published the comparative results. (I have an unfair advantage. I have been able to work pretty much full-time on FOP, but there is only one of me.)

What's happened to the redesign? I have nothing to prove - you guys do. I'll just keep working, publishing design notes for anyone who is interested, and, when I get chunks of code working, I'll publish the comparisons. Shall we put them to the vote? Will a vote decide whether property handling is faster and smaller?

Note that I am quite happy to work towards integrating a fully-working FO and area tree susbsystem into the redesign. I will not devote time to hacking such a working system apart to place nuggets of the original into a design in which I, as yet, have no confidence.

I repeat - you guys are the ones who have to prove that the current line of FOP development is workable. FOP has chewed up and spat out a number of very talented developers over a number of years. Are we any closer to conformance today then we were two years ago? If not, is that my fault?

I am all for it. After I get "pluggable layout" working, and some font work
finished, that would be the direction I want to go as well.

I admit that I am more comfortable with the design of redesign than I am with alt-design. In other words, I would currently rather refactor redesign until it is readable and fixable than to embrace pull parsing.

There are some rather large assumptions in what is immediately above. Good luck.

Peter B. West

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

Reply via email to