--- Comment #3 from Mehdi Houshmand <> 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, 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

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:
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to