From your description, there is no noticeable overlap. You seem to be looking at relationships between siblings. However, the general discussion puzzles me a bit. I cannot see the problem with references, or to be more specific, I cannot see the problem with the disciplined use of references.
When I first started work on fop-related code, I wrote the Tree and Node classes as a general tree structure (not finding anything suitable as part of collections or some such.) It seemed to me that such a structure would actually be of assistance in designing and in understanding what was happening with the various "trees". The methods to add, copy and, particularly, delete subtrees take care of the necessary internal references. If any external references into the subtrees remain, GC on a deleted subtree will be defeated, but this is a general problem.
All of this adds overhead, but it also adds structure and comprehensibility. I am continually feeling chastened by the sound design and implementation principles expressed in this group. That makes it even more puzzling to me that an structure as central as a tree is not given direct expression.
It seems to me that the relationships within and across the Area tree require more, not less, structure and the necessary abstractions to express that structure. Node has, e.g., PrecedingSibling and FollowingSibling iterators. There may be more efficient ways to express iteration states than in Iterator objects, but the principle of a general provision for such operations is surely sound.
I may have missed the point in this particular discussion and leapt off on a tangent, but I hope it has some bearing.
Peter
Victor Mote wrote:
Jeremias Maerki wrote:
Hmm, I'm no specialist in this area but wouldn't this be part of the property refinement which lies within the scope of Peter's work to be integrated with the trunk? I just hope you guys don't do the work twice. You two better stick your heads together. Just a thought.
I don't think it is related to property refinement, although it could/should be related to the "formatting object tree" and "refined formatting object tree", which have already been well-documented not to exist in their entirety under our processing model before layout starts. If they did exist, then text-transform could be done as part of the transformation from one to the other. However, under our model, it has to be done on the fly. More on this in my response to Keiron to follow.
Peter, if you are addressing text-transform as part of your property refinement work, please do let me know.
-- 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]
