Hi people,

Simply a FYI to let you all know that I'm still working on marker property resolution, which is just taking a little longer than I had anticipated... :(

AFAICT, currently all properties are all handled nicely and evaluated correctly --including percentage values and 'em' values. The only thing still bugging me is the white-space handling, but I'm definitely getting closer to a commit.

Turns out the easiest way to achieve the desired result was to:

- alter MarkerPropertyList
  -> override addAttributesToList() to store the 'naked' attribute info
(the original Attributes can't be used; they will be long gone by the time
      the actual resolving takes place)
  -> getExplicit() / putExplicit() get a null implementation
     (they won't be used anyway)
  -> implement the Attributes interface, so the MarkerPropertyList
     itself can be fed into the addAttributesToList() for another
     PropertyList subtype

As such, FONode.processNode() can be used in RetrieveMarker to process the clone: bind it to a freshly instantiated StaticPropertyList, passing it the MarkerPropertyList as Attributes.

- removed the addChildNode() step from the cloning process; instead added a protected static method FObj.addChildTo() taking two parameters --child and parent-- which RetrieveMarker can call explicitly after the cloned FO has been processed. The fact that the addition of the child node was performed immediately upon cloning, was causing headache upon headache here, so I decided to mimick more or less what happens in FOTreeBuilder:
 1) create the node (clone)
 2) process
 3) add to parent


Also detected and corrected some minor bugs:
When cloning a table only the child nodes (=bodies) were cleared/ cloned, not the columns, table-header and -footer. Analogously, for FOText, the original FOText.ca was kept. I added a System.arracopy in there to make sure the char array is really a different one. White-space handling would remove some of the whitespace, which could turn out to give incorrect results if the marker is retrieved a second time in a context with different white- space related properties.


Unfortunately, still can't commit, since two other testcases are still failing:
- one concerning white-space handling in markers (marker_bug.xml)
- one concerning column-numbers (table-cell_number-rows- spanned_bug38397.xml)

A third one failed, but this was a different story, as I was playing around with adding strict validation to the property resolution. Don't know if the behaviour was actually correct, but test-case 'block_font-style.xml' didn't pass validation because of an invalid value for font-style... Anyway, I deactivated this again, and only added strict validation FTM on the property-names.


Later,

Andreas

Reply via email to