https://issues.apache.org/bugzilla/show_bug.cgi?id=51052
--- Comment #3 from Mehdi Houshmand <[email protected]> 2011-04-14 04:08:22 EDT --- After further looking into this, it appears as if the validateChildNode() was never intended to validate #PCDATA (or in our its object representation FOText). I say this because (as Andreas eluded to) FObjMixed is the progenitor of all the classes that create FOText. And these are the only objects that can accept #PCDATA as a child, so no validation really needs to be done on FOText, with respect to validateChildNode(). However, o.a.f.fo.flow.Marker inherits from FObjMixed, and so when Marker.characters() is called, it blindly creates an FOText object without checking the validity of the #PCDATA. One solution would be to store the character array (or as a String) and postpone the creation of the FOText node, until the Marker is retrieved by the retrieve marker, and thus validation can be done. The point at which both the marker and the retrieve marker are both accessible seems to be in AbstractPageSequenceLayoutManager.resolveRetrieveMarker(). Arguably, this object shouldn't be responsible for validation, so if we inspect resolveRetrieveMarker(), we find that AbstractRetrieveMarker.bind() is responsible for binding a Marker to a RetrieveMarker. It is possible that, just prior to this, we validate the children of the marker and either invoke the creation of an FOText object or trigger an event to display the error. I thought this would be a quick fix, but now I'm not so sure. I don't know what the ramifications of postponing the creation of the FOText node will have. Nor if it's possible to postpone the creation since FObjMixed.flushText() seems to be responsible for binding the FOText object to a Block, and it's class private. I'm afraid I don't have the time at the moment to investigate this further, but if and when I come back to it, or if anyone else want's to take a stab at this, it may save some time. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
