Another problem with Marker.rebind()

[Simon Pepping <sp...@leverkruid.nl>]

I noticed another problem with Marker.rebind(): When the same marker
is retrieved more than once, the first rebind is overwritten with the
second. See this example:

    <fo:static-content flow-name="xsl-region-after">
      <fo:block text-align="start">
        <fo:inline color="red">red: <fo:retrieve-marker retrieve-class-name="class" retrieve-boundary="page" retrieve-position="first-starting-within-page"/></fo:inline>,
        <fo:inline color="blue">blue: <fo:retrieve-marker retrieve-class-name="class" retrieve-boundary="page" retrieve-position="first-starting-within-page"/>.</fo:inline>
      </fo:block>
    </fo:static-content>

Both markers are printed in blue. Perhaps it would be a solution to
clone the subtree below the marker to retrieve-marker, and rebind that
copy. That would be another example of layout dependent data in the FO
tree. If every retrieve-marker would always discard its existing
subtree and copy the subtree under the retrieved marker in
LM.preloadnext(), this would prevent later runs with the same FO tree
from reusing markers that would pertain to the layout of an earlier
run.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

RE: Another problem with Marker.rebind()

[Victor Mote <vi...@outfitr.com>]

Simon Pepping wrote:

> Both markers are printed in blue. Perhaps it would be a 
> solution to clone the subtree below the marker to 
> retrieve-marker, and rebind that copy. That would be another 
> example of layout dependent data in the FO tree. If every 

Just by way of clarification, this is no doubt de facto true in the current
FOP HEAD code, but, depending on the design, IMO it is not a necessity.
Peter West and I discussed this some, probably around August of 2003. I
thought at the time that a GraftingPoint interface which lived in the FOTree
could be used to handle this concept without disrupting the independence of
the FOTree. I am now of the opinion that the solution may be even simpler.
If you take the idea that the AreaTree is a "view" of the FOTree, so that
Areas essentially inherit and/or derive traits from their generated-by
FOTree nodes (instead of having bound values cached in them), then the
solution may be as simple as using some redirects when static content is
involved. This depends, in turn, on late binding (really, no binding) of the
property values, which does not appear to be possible with the current FOP
design. I am close to being able to demonstrate all of this within FOray,
but I am not sure whether I will get it done in time for the upcoming 0.2
release, although it will have an independent FOTree.

Victor Mote