Arved Sandstrom wrote:
In a sense, we have four. Although xslfo-proc is being developed inYou'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.
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.
A comprehensive vision, no. But what I consider to be some necessaryThe 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?
elements of the solution, yes. And I firmly believe that the problem is comprehensively solvable.
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.No, 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?
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 alt.design 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.
Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ "Lord, to whom shall we go?" --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
