Summary Marker Property/Percentage Resolution (was: Re: DO NOT REPLY [Bug 39560] ... )

[Andreas L Delmelle <a_...@pandora.be>]

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