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 Andreas L Delmelle <a_...@pandora.be> on 2006/06/11 03:56:39 UTC
percentage resolution in markers (was: Re: DO NOT REPLY [Bug 39560] ...)
On Jun 8, 2006, at 14:30, Andreas L Delmelle wrote:
Some more follow-up on the problem WRT percentage resolution in markers:
> <snip />
> RetrieveMarkers are resolved in the parent's createChildLMs(), in
> iterating over the list of childNodes. Subsequently, the
> RetrieveMarker is unable to reparent the cloned subtree to its own
> parent, since this would lead to a ConcurrentModificationException...
>
> It's probably going to be easier to get the percentage resolution
> to point to the RetrieveMarker's parent in case it encounters a
> RetrieveMarker.
I'm not so sure anymore which one of the two options will be easier...
Debugging further showed me that getBaseLength() is being called with
the descendant of a Marker as parameter (the original one, not the
clone ?)
So I dug deeper, as this behaviour seemed rather peculiar to me. It
got even stranger as I put the breakpoints earlier. The
layoutmanagers are created as they should: with the cloned marker
descendants as their base FO. No problem so far. However, when you
look at the code in Marker, a special subtype of PropertyList is
created, and therein lies the problem, I think.
My suspicion that the percentage resolution is done purely via the
FOs pointed to by the PropertyList turned out to be correct, and what
I'm currently looking at is rather nasty... 8)
The PropertyLists stored in the marker are created based on the
original FOs, which means, IIC that all LengthBases or instances of
derived classes in that PropertyList get a reference to the original FO.
Later on, when RetrieveMarker is resolved, the marker descendants are
cloned and the clones are then bound to these PropertyLists (=Map
descPLists in Marker.java).
As a result, the percentage resolution tries to climb a tree of LMs
that was never created (there is no LM corresponding to the original FO)
Took a while to track down. Now all we need is a clean solution... :/
To Be Continued
Later,
Andreas
Re: percentage resolution in markers (was: Re: DO NOT REPLY [Bug 39560] ...)
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Sounds like the right approach, since the property inheritance needs to
be going up the hierarchy after the retrieve-marker has been resolved. I
hope it's not too difficult to implement. I haven't taken a closer look
myself.
On 11.06.2006 15:28:57 Andreas L Delmelle wrote:
> On Jun 11, 2006, at 03:56, Andreas L Delmelle wrote:
>
> Just FYI:
> > Some more follow-up on the problem WRT percentage resolution in
> > markers:
> >
> > <snip />
> > My suspicion that the percentage resolution is done purely via the
> > FOs pointed to by the PropertyList turned out to be correct, and
> > what I'm currently looking at is rather nasty... 8)
> >
> > The PropertyLists stored in the marker are created based on the
> > original FOs, which means, IIC that all LengthBases or instances of
> > derived classes in that PropertyList get a reference to the
> > original FO.
> > Later on, when RetrieveMarker is resolved, the marker descendants
> > are cloned and the clones are then bound to these PropertyLists
> > (=Map descPLists in Marker.java).
> > As a result, the percentage resolution tries to climb a tree of LMs
> > that was never created (there is no LM corresponding to the
> > original FO)
>
> I think the correct way to solve this, is to have the Markers store
> references, not to the PropertyLists, but to the original Attributes.
> pList.addAttributesToList() should be called only after the clone is
> created.
>
> IOW: simply defer that call for every passing node when
> 'IN_MARKER_CONTEXT' (=non-existing variable, member of Flow?), and
> instead store the Attributes of the Marker descendants in the
> HashMap. The PropertyList should also be instantiated only during the
> cloning process (the clone needs to be passed to its constructor to
> make everything work correctly).
>
> The intention of the MarkerPropertyList subtype seems correct, but it
> doesn't go far enough (should store the original Attributes instead
> of the parsed explicit properties; once they're parsed the damage is
> already done, so to speak).
>
>
> Later,
>
> Andreas
Jeremias Maerki
Re: percentage resolution in markers (was: Re: DO NOT REPLY [Bug 39560] ...)
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Jun 11, 2006, at 03:56, Andreas L Delmelle wrote:
Just FYI:
> Some more follow-up on the problem WRT percentage resolution in
> markers:
>
> <snip />
> My suspicion that the percentage resolution is done purely via the
> FOs pointed to by the PropertyList turned out to be correct, and
> what I'm currently looking at is rather nasty... 8)
>
> The PropertyLists stored in the marker are created based on the
> original FOs, which means, IIC that all LengthBases or instances of
> derived classes in that PropertyList get a reference to the
> original FO.
> Later on, when RetrieveMarker is resolved, the marker descendants
> are cloned and the clones are then bound to these PropertyLists
> (=Map descPLists in Marker.java).
> As a result, the percentage resolution tries to climb a tree of LMs
> that was never created (there is no LM corresponding to the
> original FO)
I think the correct way to solve this, is to have the Markers store
references, not to the PropertyLists, but to the original Attributes.
pList.addAttributesToList() should be called only after the clone is
created.
IOW: simply defer that call for every passing node when
'IN_MARKER_CONTEXT' (=non-existing variable, member of Flow?), and
instead store the Attributes of the Marker descendants in the
HashMap. The PropertyList should also be instantiated only during the
cloning process (the clone needs to be passed to its constructor to
make everything work correctly).
The intention of the MarkerPropertyList subtype seems correct, but it
doesn't go far enough (should store the original Attributes instead
of the parsed explicit properties; once they're parsed the damage is
already done, so to speak).
Later,
Andreas