Arved Sandstrom wrote:
You're being absolutely honest, which is cool - I'll be absolutely honest
also. It seems to me like the mainstream rewrite is in trouble. Very few
people understand it or have [clearly] bought into it. This is no comment on
its technical merits, by any means.

OTOH, only one person has been working on the alternative - you yourself,
Peter. So what we really have is 3 projects: maintenance, rewrite, and
alternative, and most of the committers and developers seem to be working on
maintenance. Correct me if I'm wrong.
In a sense, we have four. Although xslfo-proc is being developed in
another place and language, you are still very much a part of this
development community, active of not. I nominate xslfo-proc as the
fourth project because, to the best of my knowledge, you and Eric are
taking a different approach to design again. And the design, as you
point out, is the critical issue. Whatever success you have with design in xslfo-proc should be of great interest here.

The problems you describe in your email are symptoms, in my opinion. Forrest
is irrelevant...we have bigger problems. In fact, pull vs push vs tree is
also irrelevant, because that is dancing around the big issues -
understanding the FO spec, and being able to implement it. Has anyone so
far, for example, described a clear vision for properly handling keeps?
A comprehensive vision, no. But what I consider to be some necessary
elements of the solution, yes. And I firmly believe that the problem is comprehensively solvable.

they haven't. Does anyone here think the FO problem is non-deterministic?
Raise your hands, please. :-) No? In which case, why (years after this
project started) do we not have clear algorithms stating exactly what we
will do in various situations?
This is the question that everyone has to answer. Blind faith that that the problem can be solved by simply hurling onself at it is not enough. I'm not saying that Keiron and Karen are in that situation, but I suspect that others are. An elegant and comprehensive plan of attack, including a design approach that can confidently be expected to crack the toughest problems, may exist in their imaginations, but it needs to be made manifest before any sort of team attack can be made on the problems.

My impression though (and I am happy to have my ignorance corrected on
this) is that the redesign is being attempted piecemeal, without a broad
overview. If I am correct in this, it would be largely explained by the
complexity of the problem, and the determination to retain as much as
possible of the existing code base, and therefore, of the existing design. If I am wrong in this, it may be symptomatic of, in addition to my laziness and obtuseness, inadequate top-level documentation (including diagramming) of the way the layout is attacked.

Whether or not those considerations actually apply in this case, if you
are using piecemeal design as a way to attack complexity, you must be
prepared to throw things away when they prove not to be fruitful, as
many things inevitably will.

 I could care less at this point about SAX and
DOM and pull and push - that's XML processing. Our FO processing algorithms,
stated in design notes, should express independently of XML processing model
how we will handle every FO situation.
I agree with you here.  By the time the layout is triggered in the
current model, the relevant part of the FO tree has been built, so the
layout engine is always working on a complete subtree.  However, it
seems to me that the existing design, and possibly the redesign, do not
take full advantage of this.  The has the advantage of being
based on an explicit, fully navigable tree structure.  However, that
structure is not, in itself, sufficient to express the relationships
needed for layout.  We have had discussions in the past about tree vs.
flat structures for the area tree.  I believe that both views are needed
simultaneously, and that the "flat" view can be obtained by running
"threads" of links through the tree to represent page-contiguous
elements for the resolution of keeps and space-specifiers, for example.

I am not dismissing your concerns, Peter. I just think that we've got bigger
ones. We are the committers; we need to decide once and for all what we
intend to do. If it assuages your feelings any, I happen to be partial to
your pull model - I am personally very comfortable with SAX, but I recognise
that most are not.
"Lord, to whom shall we go?"

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

Reply via email to