On Dec 17, 2007, at 11:20, Vincent Hennebert wrote:
One last thing:
int end,
PropertyList pList,
Locator locator) throws FOPException {
- /* Only add text if the fo:wrapper is not a child of an
fo:flow
- * or fo:static-content */
- if (!this.isFlowChild) {
+ /* Only add text if the fo:wrapper's parent allows inline
children */
+ if (this.inlineChildrenAllowed) {
super.addCharacters(data, start, end, pList, locator);
IIUC, this check isn’t necessary? If test children weren’t allowed
this
would have been caught by the validateChildNode method?
No, because validateChildNode() is not called for text-nodes.
See FOTreeBuilder.MainFOHandler:
-> startElement() is where validateChildNode() is called to validate
the incoming node against the current FO.
If it is not a valid child, no FONode is even created for it and
FOP will throw an Exception (FONode.invalidChildError() or some other
variant)
-> characters() calls the current FONode's addCharacters() method,
which is only implemented in the FObjMixed subtype. The default
implementation does nothing.
One could argue that the default characters() event should also do
some form of validation, but that could turn out to be very tricky.
The SAX parser is obliged to report *all* characters (including
possible ignorable whitespace). We would already need to perform
space-normalization here to make sure there really are stray
characters in places where they do not belong...
For now, the strategy is simply to ignore any characters, unless they
appear in FO types that allow #PCDATA content (FObjMixed subtypes).
As a consequence, something like this goes unpunished:
<fo:root ...>
Some text here
<fo:layout-master-set>
...
Maybe we could make the default implementation in FObj display a
warning, but as indicated above, we would need to sort out whether
the text really doesn't belong there, or whether it is simply a white-
space-only node.
Cheers
Andreas
