You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Florent Georges <da...@yahoo.fr> on 2006/03/06 00:57:47 UTC
NPE
Hi
While running some tests, I found an NullPointerException with 0.91:
~> fop contract.fo contract.pdf
Exception
java.lang.NullPointerException
Attached the contract.fo file. I'm sorry I don't have time to locate
more precisely the error to reduce the size of this file (I have to
continue some work now and its not an error I find in "real files").
I'm sorry too I had to delete the text from this file (it's maybe
harder to read).
Hope that helps. Regards,
--drkm
___________________________________________________________________________
Nouveau : t�l�phonez moins cher avec Yahoo! Messenger ! D�couvez les tarifs exceptionnels pour appeler la France et l'international.
T�l�chargez sur http://fr.messenger.yahoo.com
Re: NPE
Posted by Glen Mazza <gm...@apache.org>.
Andreas L Delmelle wrote:
> In the latter case, however:
>
> <fo:instream-foreign-object>
> <svg:svg ...>
> ...
> </svg:svg>
> </fo:instream-foreign-object>
>
> Note that the i-f-o now contains two text nodes (= #PCDATA):
> '
  ' and ' '
>
I think they call that "insignificant white space", and that would not
be counted as PCDATA. Partly explained here, but not definitive either way:
http://www.w3.org/TR/REC-xml/#sec-white-space
Also, this old email[1], which included the above link, has an
interesting quote of how to interpret whitepace:
Whitespace verifies as #PCDATA if #PCDATA is allowed at a particular
point. If #PCDATA is NOT allowed at a particular point, the whitespace
is ignored for the purposes of verifying.
[1] http://lists.xml.org/archives/xml-dev/199806/msg00386.html
But I'm far from an expert on this stuff.
> This means we have a choice to either test every one of those
> characters, or let the 'error' slip through, possibly with a warning.
> Depending on the context, I can imagine users not being very happy if
> FOP were to be unconditionally strict here... [suppose i-f-o is on one
> of the last pages of a 250 page document :-/]
>
I don't think that whitespace-only nodes are being created by FOP
anyway, if the whitespace just exists between two consecutive opening
tags. So this problem may not be occuring for the user as it is.
<soapbox>But it is a common misperception[2] that strict validation is
mean and cold-hearted, when in fact is it saves people from submitting
erroneously built documents/invoices. "Just a warning" means that the
user is required to scroll through the log output of every document
generation, just to make sure that the document FOP produced is valid,
and if they fail to do that, then they may submit an incorrect document
or invoice. For every hacker irritated by strict validation, two or
three are probably saved by it--especially billing invoices, where you
almost certainly would want to halt if you had an XSLT error which would
otherwise cause an invalid invoice to be created.</soapbox>
Thankfully FOP has both a strict and non-strict version to suit either
preference. Human nature being what it is though, most who clamor for
the latter, as soon as it is provided to them, start using the former
anyway.
Glen
[2] http://marc.theaimsgroup.com/?l=fop-dev&m=111365780207108&w=2
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: NPE
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Mar 7, 2006, at 02:38, Glen Mazza wrote:
Hi Glen,
> Andreas L Delmelle wrote:
>
>> On Mar 6, 2006, at 10:05, Florent Georges wrote:
>>>
>>> The fo:instream-foreign-object flow object has a child
>>> from a non-XSL namespace. The permitted structure of
>>> this child is that defined for that namespace.
>>>
>>> So it is required to an IFO to have a child element, isn't
>>> it?
>> Yes. Exactly one child that is not in the XSL-FO namespace.
>>> And to don't have non-whitespace #PCDATA. Right?
>> Hmm... Yes, if I catch your intention correctly.
>>> So an FO validator would have to report an error for both the
>>> above IFOs, isn't it?
>> I'd think so, yes. OTOH, if you have an i-f-o that contains some
>> text, and then a foreign XML node, I'd assume that a warning
>> would suffice...
>
> I disagree, although not enough to resubscribe to FOP-DEV and veto
> such a matter. PCDATA isn't allowed for fo:i-f-o. Those FO's
> which may have PCDATA are expressly defined in the XSL specification.
I see your point... maybe we can do something with the
strictValidation switch here. My concern here is that the first two
cases are obviously wrong (since the required non-XSL child node is
absent).
In the latter case, however:
<fo:instream-foreign-object>
<svg:svg ...>
...
</svg:svg>
</fo:instream-foreign-object>
Note that the i-f-o now contains two text nodes (= #PCDATA):
'
  ' and ' '
This means we have a choice to either test every one of those
characters, or let the 'error' slip through, possibly with a warning.
Depending on the context, I can imagine users not being very happy if
FOP were to be unconditionally strict here... [suppose i-f-o is on
one of the last pages of a 250 page document :-/]
Any other opinions on this?
Cheers,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: NPE
Posted by Glen Mazza <gm...@apache.org>.
Andreas L Delmelle wrote:
> On Mar 6, 2006, at 10:05, Florent Georges wrote:
>
>> Andreas L Delmelle wrote:
>>
>>> On Mar 6, 2006, at 01:25, Florent Georges wrote:
>>
>>
>>> Well, AFAICT, it's not really empty from a SAX parser's
>>> point of view. It does contain a text-node, but this is
>>> completely ignored by FOP. The SAX characters() events are
>>> only handled for FOs that can contain #PCDATA.
>>
>>
>> Mmh, I'm not sure to understand. The document contains
>> some:
>>
>> <fo:instream-foreign-object/>
>>
>> as well as some:
>>
>> <fo:instream-foreign-object>...</fo:instream-foreign-object>
>>
>> I guess you only saw the later. Furthemore, if I
>> understand right §6.6.6 (mmh, ok, born to be a problematic
>> paragraph :-p):
>
>
> Yep, my mistake, I only saw the latter. Anyway, what I mean is that the
> SAX Parser used with FOP will report those three '.' characters. That
> is: any compliant XML parser MUST report those characters to the
> application. Only FOP does nothing with them, and those characters are
> ignored.
>
>> Contents:
>>
>> The fo:instream-foreign-object flow object has a child
>> from a non-XSL namespace. The permitted structure of
>> this child is that defined for that namespace.
>>
>> So it is required to an IFO to have a child element, isn't
>> it?
>
>
> Yes. Exactly one child that is not in the XSL-FO namespace.
>
>> And to don't have non-whitespace #PCDATA. Right?
>
>
> Hmm... Yes, if I catch your intention correctly.
>
>> So an FO validator would have to report an error for both the
>> above IFOs, isn't it?
>
>
> I'd think so, yes. OTOH, if you have an i-f-o that contains some text,
> and then a foreign XML node, I'd assume that a warning would suffice...
>
I disagree, although not enough to resubscribe to FOP-DEV and veto such
a matter. PCDATA isn't allowed for fo:i-f-o. Those FO's which may have
PCDATA are expressly defined in the XSL specification.
I would rather every FOP-accepted XSL stylesheet be accepted by every
commercial processor, than have the reverse, as the reverse would
require watering down our validation to the extent that a FOP-accepted
stylesheet is no longer a guarantee of XSL compliance (or anything
else.) "If your stylesheet is accepted by FOP it is as good as gold" is
a nice selling point.
Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: NPE
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Mar 6, 2006, at 10:05, Florent Georges wrote:
> Andreas L Delmelle wrote:
>
>> On Mar 6, 2006, at 01:25, Florent Georges wrote:
>
>> Well, AFAICT, it's not really empty from a SAX parser's
>> point of view. It does contain a text-node, but this is
>> completely ignored by FOP. The SAX characters() events are
>> only handled for FOs that can contain #PCDATA.
>
> Mmh, I'm not sure to understand. The document contains
> some:
>
> <fo:instream-foreign-object/>
>
> as well as some:
>
> <fo:instream-foreign-object>...</fo:instream-foreign-object>
>
> I guess you only saw the later. Furthemore, if I
> understand right §6.6.6 (mmh, ok, born to be a problematic
> paragraph :-p):
Yep, my mistake, I only saw the latter. Anyway, what I mean is that
the SAX Parser used with FOP will report those three '.' characters.
That is: any compliant XML parser MUST report those characters to the
application. Only FOP does nothing with them, and those characters
are ignored.
> Contents:
>
> The fo:instream-foreign-object flow object has a child
> from a non-XSL namespace. The permitted structure of
> this child is that defined for that namespace.
>
> So it is required to an IFO to have a child element, isn't
> it?
Yes. Exactly one child that is not in the XSL-FO namespace.
> And to don't have non-whitespace #PCDATA. Right?
Hmm... Yes, if I catch your intention correctly.
> So an FO validator would have to report an error for both the
> above IFOs, isn't it?
I'd think so, yes. OTOH, if you have an i-f-o that contains some
text, and then a foreign XML node, I'd assume that a warning would
suffice...
Cheers,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: NPE
Posted by Florent Georges <da...@yahoo.fr>.
Andreas L Delmelle wrote:
> On Mar 6, 2006, at 01:25, Florent Georges wrote:
> > Andreas L Delmelle wrote:
> >> The problem is an empty fo:instream-foreign-object.
> > Thanks for the solution (mmh, this file passed my
> > validator, I'll have to check that).
> Well, AFAICT, it's not really empty from a SAX parser's
> point of view. It does contain a text-node, but this is
> completely ignored by FOP. The SAX characters() events are
> only handled for FOs that can contain #PCDATA.
Mmh, I'm not sure to understand. The document contains
some:
<fo:instream-foreign-object/>
as well as some:
<fo:instream-foreign-object>...</fo:instream-foreign-object>
I guess you only saw the later. Furthemore, if I
understand right §6.6.6 (mmh, ok, born to be a problematic
paragraph :-p):
Contents:
The fo:instream-foreign-object flow object has a child
from a non-XSL namespace. The permitted structure of
this child is that defined for that namespace.
So it is required to an IFO to have a child element, isn't
it? And to don't have non-whitespace #PCDATA. Right? So
an FO validator would have to report an error for both the
above IFOs, isn't it?
PS: I based my validator on the RNC grammar provided by
RenderX at <URL:http://www.renderx.com/tools/validators.html>.
Regards,
--drkm
___________________________________________________________________________
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.
Téléchargez sur http://fr.messenger.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: NPE
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Mar 6, 2006, at 01:25, Florent Georges wrote:
> Andreas L Delmelle wrote:
>
>> The problem is an empty fo:instream-foreign-object.
>
> Thanks for the solution (mmh, this file passed my validator, I'll
> have to check that).
Well, AFAICT, it's not really empty from a SAX parser's point of
view. It does contain a text-node, but this is completely ignored by
FOP. The SAX characters() events are only handled for FOs that can
contain #PCDATA.
Cheers,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: NPE
Posted by Florent Georges <da...@yahoo.fr>.
Andreas L Delmelle wrote:
> The problem is an empty fo:instream-foreign-object.
Thanks for the solution (mmh, this file passed my validator, I'll
have to check that).
Regards,
--drkm
___________________________________________________________________________
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.
Téléchargez sur http://fr.messenger.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: NPE
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Mar 6, 2006, at 00:57, Florent Georges wrote:
Hi,
> While running some tests, I found an NullPointerException with 0.91:
>
> ~> fop contract.fo contract.pdf
> Exception
> java.lang.NullPointerException
>
> Attached the contract.fo file.
The problem is an empty fo:instream-foreign-object.
Just patched FOP Trunk so now a ValidationException is thrown instead
of an NPE.
Cheers,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org