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

> 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
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 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. 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 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 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]

Reply via email to