https://issues.apache.org/bugzilla/show_bug.cgi?id=51052
--- Comment #1 from Andreas L. Delmelle <[email protected]> 2011-04-13 13:25:05 EDT --- (In reply to comment #0) > The issue is that a NPE is thrown when a retrieve-marker retrieves a marker > with only text content, when the retrieve-marker is a child of a table-cell. > The real problem here is that there is no validation done on the retrieve > marker to ensure that the markers child is a valid child of the retrieve > markers parent (excuse the tongue twister), see XSL section 6.13.5: Indeed. Basic validation of child elements (i.e. FONode.validateChildNode()) is skipped when the marker is cloned. That seems like an oversight. > Though the spec doesn't specify how to handle this error, I am proposing that > rather than throw an NPE, FOP logs a warning and ignores the marker. Exactly. That would remain consistent with the behavior during normal FO tree building. If some bare text is entered in a fo:table-cell (or basically any FO that expects block-content), then it will be ignored, rather than reported as an error. To remain consistent, we would have to match this behavior. So, if the child node is a FOText and the retrieve-marker's parent is not a FObjMixed, we should at most issue a warning, and assume 'no content'. > The spec doesn't specifically suggest that this kind of error is > recoverable, but others > might agree that throwing an NPE isn't the "proper" way to deal with this > error. Definitely. Rule of thumb: a NPE is *always* wrong. :-) > > I've attached an example test FO and I'll attach a patch shortly. Thanks! -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
