Hi Andreas,

Andreas L Delmelle wrote:

> 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.

Hmmm, this is unfortunate IMO. That makes validation unreliable, and 
that forces to implement hacks like in Wrapper.


> 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...

Well it’s not the same kind of normalization as required by the 
Recommendation. For objects accepting mixed content we would accept any 
kind of text node, and the proper normalization would indeed be done 
later.
For the other objects we just need to know if the text node contains XML 
whitespace only (space, tab, line-feed, carriage-return). Something like 
String.trim().length() == 0 should be enough for the validation. WDYT?


> Hmm, now that I did look at that call closer...
> 
> What is the meaning of:
> 
> try {
>   currentFObj.validateChildNode(...);
> } catch (ValidationException e) {
>   throw e;
> }
> ?
> 
> Unless we're really going to add something in that catch-block, this
> seems completely redundant here.

Yes, you can safely remove that.

Vincent


-- 
Vincent Hennebert                            Anyware Technologies
http://people.apache.org/~vhennebert         http://www.anyware-tech.com
Apache FOP Committer                         FOP Development/Consulting

Reply via email to