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. 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. 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. 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. 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. > In making those notes, I have been at pains to illustrate my points with > either new diagrams or reference to existing ones. I have gone to those > lengths because I an anxious to communicate my ideas as accessibly as > possible. When I was working on the properties implementation, I found > that my attempts to explain what I was doing were met with blank > incomprehension. I am trying more diligently to circumvent such a > situation now. > > However, it seems that I am still working in something of a vacuum. I > have had a little feedback, but it did not relate specifically to the > possible impact of my ideas or the alt.design properties integration, on > the design of layout. 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". > 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. > Add to this the opacity of the code itself, evidenced by a number of > Joerg's comments over the past few months, and I think there is good > cause for extensive documentation and diagramming of the intention and > direction of the design, and of various critical algorithms, using a > combination of text, diagrams and code fragments, in a way similar to > the approach I have been attempting with the alt.design documention and > recent discussions. 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. > The easiest way to proceed is to hack existing code. It's the > conventional wisdom, it gives instant gratification and feedback, and > one always has something that works - sort of. Granted, the HEAD base > incorporated new design approaches when it was initiated, but my feeling > is that HEAD redesign is now progressing by the above method. So far, > this approach to development has not succeeded in resolving the thornier > design issues thrown up by the Rec. I'm not saying that Kieron, Joerg > and yourself will not succeed where others have failed. But I would > like to see the process made as transparent as possible. (Your work on > the rationalisation of the web site is a step in that direction.) My gripes with the redesign have less to do with the design (which /seems/ plausible), and more to do with what you call the "opacity of the code". Well-written code should almost be self-documenting. However, neither a bad design, poor implementation, or unreadable redesign code necessarily speak in favor of alt-design. 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. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
