On Jun 15, 2006, at 18:42, Andreas L Delmelle wrote:
<snip />
Ok, final summary of what I'm going to attempt:
-> introduce an inMarker boolean switch in the FOTree
still a few doubts on where to store this, but the Flow seemed like
a good candidate (markers have to be flow-descendants)
OTOH, FOEventHandler also seems OK, and has the advantage of being
readily accessible from everywhere through FObj.getFOEventHandler()
(and thus, FOEventHandler subclasses, like the RTFHandler, would
also
be able to make use of it?)
other use-case of this switch: turn off white-space handling, and
defer it to the marker-retrieval context (integrate into the cloning
process)
-> alter FOTreeBuilder$MainFOHandler.startElement()
if node is a Marker, switch context (inMarker = true)
when inMarker is true:
no call to FONode.createPropertyList(), and pass null as property
list into FONode.processNode()
when inMarker is false:
same as before
-> alter FOTreeBuilder$MainFOHandler.endElement()
if node is a Marker, switch context (inMarker = false)
-> alter FObj.processNode()
when inMarker is true:
no binding of the FO to the property list (which will be null
anyway),
merely keep a reference to the original Attributes (somehow I'd
expect
these to be smaller than a corresponding PropertyList, but in
the end,
this depends on the XML parser implementation? Slightly more
than a Map?)
when inMarker is false and pList is null
avoid NPE (shouldn't happen, but you never know)
when inMarker is false and pList not null
same as before
-> in RetrieveMarker, right after the marker-children are cloned, call
clone.createPropertyList(), feeding it the storedPropertyList and
the Attribute.
Then call clone.processNode(). Maybe RetrieveMarker also needs a
currentProperyList, like FOTreeBuilder, in order to pass the
proplist
down in to the subtree when cloning.
This should fix the percentage resolution, as well as the bug
concerning evaluation of relative font-sizes (ems) in Markers. All
property parsing/resolution for marker descendants will be deferred,
and performed only when the marker is actually retrieved.
FTM, nothing will be changed where it comes to the cloning process.
Simon's idea of reusing the original FObjs is definitely interesting,
but it would also mean that they need to be reparented to the Marker
after the LMs are created, and their properties (instance variables)
would need to be reset. Problems may arise if this is done, and
afterwards the LM accesses the instance variables of its FObj... I'm
not sure whether it's doable. :/
The RetrieveMarkerPropertyList question is less urgent (merely
streamlining, no bugfixing).
Back to work! :)
Later,
Andreas
