Keiron Liddle 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 toget
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 m
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.200
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 r
Keiron Liddle wrote:
> This sounds more like a layout thing.
> If you are going to find complete words to do some manipulation
> then I would
> suggest taking a look at the "getWordChars" method in the layout
> managers. This
> is used to gather together all strings in from different layout
> mana
Keiron Liddle wrote:
> If I can remember correctly, it was done for a few reasons.
...
> The other is to reduce references in the fo tree.
I'll have to think about this some more, but how can we even say that it is
part of the fo tree if we don't know what its parent element is?
Victor Mote
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 though
> 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 o
Hi Victor,
If I can remember correctly, it was done for a few reasons.
Originally it was using the parent to load properties, it would then store these
properties in variables and pass them to methods when doing layout.
It is possible that the same parent could have more than one FOText child cre
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 Victo
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 Blo
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 introd
12 matches
Mail list logo
