You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Victor Mote <vi...@outfitr.com> on 2003/03/20 19:03:25 UTC
FOText constructor (trunk)
There is a change between the maintenance branch & the redesign (trunk) that
I do not understand. The constructor for FOText no longer has its parent
node as a parameter as it did in the maintenance branch. Does anyone know
the purpose of this? FWIW, it was part of the very first revision after the
maintenance branch was created (rev 1.25). Specifically, is it a problem if
I put it back in?
Victor Mote (mailto:vic@outfitr.com)
2025 Eddington Way
Colorado Springs, Colorado 80916
Voice +1 (719) 622-0650
Fax +1 (720) 293-0044
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: FOText constructor (trunk)
Posted by "Peter B. West" <pb...@powerup.com.au>.
Jeremias,
I wouldn't call your contributions noise. I'm pleased my feedback was
useful.
Peter
Jeremias Maerki wrote:
> You made me think again, Peter. I believe I'm wrong in what I said
> earlier in this thread about child-to-parent references. Seems like I
> mixed up things that I learned back in my Delphi days when one had to do
> reference-counting. I'm going over my changes again... Sorry for the
> noise.
--
Peter B. West pbwest@powerup.com.au http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: FOText constructor (trunk)
Posted by Jeremias Maerki <de...@greenmail.ch>.
You made me think again, Peter. I believe I'm wrong in what I said
earlier in this thread about child-to-parent references. Seems like I
mixed up things that I learned back in my Delphi days when one had to do
reference-counting. I'm going over my changes again... Sorry for the
noise.
On 23.03.2003 02:12:00 Peter B. West wrote:
> 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.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: FOText constructor (trunk)
Posted by "Peter B. West" <pb...@powerup.com.au>.
Victor,
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 pbwest@powerup.com.au http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: FOText constructor (trunk)
Posted by Victor Mote <vi...@outfitr.com>.
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.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: FOText constructor (trunk)
Posted by Jeremias Maerki <de...@greenmail.ch>.
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.
On 20.03.2003 21:59:59 Victor Mote wrote:
> Jeremias Maerki wrote:
>
> > Anyway, may I ask for the reason that you want to do that?
>
> Sure. I am trying to port some code I wrote to implement text-transform for
> the maintenance branch over to the trunk. One of the key things there is to
> tie together all FOText objects that are part of the same Block, so that
> word boundaries are respected regardless of the markup. The way I
> implemented this was to keep finding ancestors until I came to a Block. I
> can't do that without the reference to the parent. It is not a high priority
> thing, but I am trying to finish up all of the stuff I started in the
> maintenance branch.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: FOText constructor (trunk)
Posted by Victor Mote <vi...@outfitr.com>.
Jeremias Maerki wrote:
> Anyway, may I ask for the reason that you want to do that?
Sure. I am trying to port some code I wrote to implement text-transform for
the maintenance branch over to the trunk. One of the key things there is to
tie together all FOText objects that are part of the same Block, so that
word boundaries are respected regardless of the markup. The way I
implemented this was to keep finding ancestors until I came to a Block. I
can't do that without the reference to the parent. It is not a high priority
thing, but I am trying to finish up all of the stuff I started in the
maintenance branch.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: FOText constructor (trunk)
Posted by Jeremias Maerki <de...@greenmail.ch>.
I can't tell. Probably not. I hope Keiron can jump in here.
The only thing that comes to my mind right now is the problem of garbage
collection. Having parent-to-child references is one thing. Having
child-to-parent references is another. In the PDF lib refactoring I'm
currently doing, I've introduced WeakReferences for child-to-parent
references so discarded objects can be garbage collected without having
to develop extensive clean-up code. Maybe something like that played in
there: Minimizing child to parent references. I really can't tell from
CVS.
Anyway, may I ask for the reason that you want to do that?
On 20.03.2003 19:03:25 Victor Mote wrote:
> There is a change between the maintenance branch & the redesign (trunk) that
> I do not understand. The constructor for FOText no longer has its parent
> node as a parameter as it did in the maintenance branch. Does anyone know
> the purpose of this? FWIW, it was part of the very first revision after the
> maintenance branch was created (rev 1.25). Specifically, is it a problem if
> I put it back in?
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org