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 alt.design 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 again.
I am a little more disturbed to hear that alt.design 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 alt.design, and some general questions of layout design.
Here is my frank take on the alt.design 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 creation.
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 alt.design 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 alt.design 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 alt.design.
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 alt.design 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 -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
