J.Pietschmann wrote:
John Austin wrote:
A high runner in FOP 0.20.5 is: PropertyList.findProperty().
It calls other functions in org.apache.fop.fo that consume
significant CPU resources. In one example it called itself
recursively to a (depth of 10)
Without taking a closer look at the code, I su
Thanks for the explanation.
Glen
--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
> Glen Mazza wrote:
> ...
> >
> > I think the next thing to consider is the storage
> of
> > specified vs. computed values. Let's say we store
> > pointers for many properties to the same
> > {"property-name", "prop
Glen Mazza wrote:
...
I think the next thing to consider is the storage of
specified vs. computed values. Let's say we store
pointers for many properties to the same
{"property-name", "property-value"} pair. A specified
property value of "10%" would not make this a very
helpful data structure if
Victor Mote wrote:
Peter B. West wrote:
...
Yes, this is the real issue. Since an fo:marker's content can be used more
than one place, this requires that its contents be "grafted" into the tree
where needed.
I think the only trick here is to pass the static content context back to
the "get" method
Victor Mote wrote:
Peter B. West wrote:
2% of what? Of a reference area. Of what actually gets laid out on a
page. If a single flow object gets laid out over more than one page,
that reference may vary, but nothing changes in the FO Tree. It makes o
sense to second-guess the Area tree within t
