Hi Richard,
Thanks for your contribution. I'll try to have a look ASAP but I'm a bit
in a hurry currently. Stay tuned.
Vincent
richardw geoquip-rnd demon co uk a écrit :
> Vincent Hennebert writes:
> > I fully agree. Good design should not be sacrificed for efficiency.
> > Anyway only the pro
Vincent Hennebert writes:
> I fully agree. Good design should not be sacrificed for efficiency.
> Anyway only the profiling of a FOP run would give us proper indications
> of what is actually eating time and memory, and where we should start
> optimizing.
If you apply the the recent patches h
Hi Andreas,
Andreas L Delmelle a écrit :
> On Mar 30, 2007, at 11:21, Vincent Hennebert wrote:
>>> In ancient times, each FO had a full PropertyList, so the properties
>>> could be queried via a generic get(PROPERTY_ID) accessor that was simply
>>> a proxy to the PropertyList's corresponding get(
On Mar 30, 2007, at 11:21, Vincent Hennebert wrote:
Hi Vincent,
I have little knowledge of the FO tree construction, so I'll perhaps
make naive questions and remarks. I write them in the hope they will
trigger further thoughts.
That was the general idea. :-)
Besides, people who are not all to
Hi Andreas,
I have little knowledge of the FO tree construction, so I'll perhaps
make naive questions and remarks. I write them in the hope they will
trigger further thoughts.
Andreas L Delmelle a écrit :
>
> Hi,
>
> Just an idea that popped in my head. I was thinking of the access to a
> FONod
Hi,
Just an idea that popped in my head. I was thinking of the access to
a FONode's properties from the layoutengine, and it became apparent
to me that ATM the approach is not too flexible: each subclass has
its own little set of private instance methods and public accessors.
This makes
