xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas L Delmelle <a_l.delme...@pandora.be>
Subject Progress update: marker property resolution
Date Sun, 06 Aug 2006 09:46:49 GMT
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

Mime
View raw message