Victor Mote wrote:
John Austin wrote:

I offered (off-line) to look merging the Alt-Design code
in to the main branch but I suspect that there are some
different directions associated with this. Perhaps this
is the reason it has not been done so far. I am still willing
to work on this but I don't want to walk in to a firefight.

FWIW, I don't think there is really a firefight. Our discussions are usually
at least robust, maybe even rowdy, but AFAICT, there is a large amount of
mutual respect. That said, we *are* still trying to sort out some design
issues. We currently have three lines of development, and I have made my
initial focus an effort to try to get that winnowed down to one as quickly
as possible. One of the three is Peter's alt-design. Here is a quick
summary, as I understand it (Peter please correct these if wrong -- I'm not
trying to misstate your case):
1. improved property handling
2. pull-parsing instead of an FO Tree (but with some data stored in memory)
3. a different layout approach

Re #1: there is general agreement that this can be improved, and performance
is only one aspect of this. As you have already found, readability is an
issue as well. Now that we have the FO Tree stuff in trunk isolated (kind
of), we can begin thinking of the FO Tree as a service or a separate
product. IOW, it can have its own API "contract" with the rest of FOP. As
long as the API remains constant, we can change the mechanical aspects
behind it without breaking anything else. Thus my comments yesterday about
changing the API first.

Re #2: this is the one that I don't yet understand. Peter and I had a thread
about six months ago that tried to resolve this, and I think he will respond
to this when he has time.

That thread was as much (or more) about #3, IIRC. Yes, uses pull parsing, but it definitely builds a tree, using the Tree and related classes that I wrote when I first became involved. The major difference is not with pull parsing (although it necessitates a different approach for extensions), but with the layout dependencies that I see as unavoidable for property resolution. (See below.)

Re #3: we have now implemented LayoutStrategy, which means that alternative
layout systems can at least theoretically be dropped into FOP. See
subsequent announcement for more information on this aspect.

And thereby hangs a tale. I started (FOP)life as a believer in the separation of property resolution and layout as sequential stages, as the Rec seems to state very clearly. In the process of trying to code the property resolution, it gradually dawned on me that such separation cannot occur. Going back to the Rec, I found the editors' escape clause. Dialogue with the editors has since confirmed that they were aware of the layout dependency for property resolution.

The question for me was, "Do I kludge around this dependency and introduce back-door methods of solving the layout feedback issues for property resolution, or do I look for a design that is up-front about this?" I was engaged in that search. The process will not be simple and clean, because the problem is not. I'll settle for coherency, robustness and comprehensibility, if I can achieve them.

The real issue for you John is whether #1 can be separated from #2 within
the alt-design stuff. I don't know the answer, since properties to me means
"FO Tree" and means something else in alt-design. I would personally be very
glad to have you look at the whole thing, being confined neither to the
status quo nor to Peter's work (but considering both), and make a
recommendation. One of the reasons for the FO Tree isolation work was to
make issues like this easier to address -- except for the FO Tree API issues
(which should be resolved first), you don't have to worry at all about
breaking layout or renderers.

Peter -- Peter B. West <>

Reply via email to