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

Reply via email to