Peter B. West wrote:

> While I don't denigrate any of these ongoing efforts, I am increasingly
> of the view that everything occurring between the reading of the fo xml
> and the layout of the area tree is interconnected in very nasty and
> intricate ways.  The description of this process in the Rec (I resisted
> the obvious temptation here) has done many developers, including the FOP
> developers, a great disservice.
>
> It's this intertwining that makes me skeptical about pluggable layout.
> It may be feasible, but I don't see that it is feasible until we have a
> very good understanding of the way layout will be achieved, and a full
> picture of the flow of control in the first full implementation.

My naive understanding of the Area Tree is that it could / should be
constructed as a "view" of the FO tree. It should not, for example, IMO,
contain any Strings at all, but objects in it should contain offset and size
values for the parent FOText object in the FO tree. Similarly, perhaps it
should not contain the trait values at all, but should compute them from the
parent on-the-fly. The FO tree should normalize the values as much as
possible (which in many cases is completely), then the Area tree can
complete whatever computation is necessary before returning the value to
use. I realize that this violates your compute-it-once principle, but I was
frankly confused by that principle. It seemed to me that the intertwining
issues that you mention utterly prevent compute-it-once.

Second, and more importantly, regardless of what design is used in the Area
Tree, there is nothing that prevents us from factoring code that is common
to more than one LayoutStrategy into a module that is usable by any
LayoutStrategy. If there are issues that force things to be intertwined,
then those could be "common" code.

> Factoring out the high-level control is still a valuable and achievable
> step forward, but I'm not sure about "control of when layout is started,
> when FO trees are destroyed."  I assume that refers to the patient vs.
> eager layout discussion.  At that level, certainly, control values can
> be factored out.

Actually the two examples listed are, in my mind, examples of the high-level
control issues that we want factored out. Patient vs. eager is only part of
the story. Also included here are such issues as reusing session and
document objects in embedded environments.

> I don't want to discourage your efforts, but I think you will need to
> keep these things in mind.

I will. Thanks. If I come back humbled from the effort, perhaps at least
some useful documentation will emerge.

Victor Mote



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

Reply via email to