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
