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 Robert Lybarger <ro...@auto-trol.com> on 2007/09/17 15:33:59 UTC
RE: migrating to 0.94 for pdf output; getting ArrayIndexOutOfBoun
ds
Hi,
To answer two replies at once:
1. An intermediate *.fo file is generated prior to being sent to FOP itself,
yes.
(PDF creation for us is a complex, multi-step process that requires this
approach.
At least as a side effect, I can trace intermediate files for problems.)
2. "indent mode" is turned off for the entire process -- turning it on tends
to
introduce whitespaces between words and punctuation where it is never
wanted,
so it's a rule/policy to only 'indent' for debugging purposes.
Our "XSLT" is basically an in-house modification of DITA toolkit (v 1.2?)
which
is rather spidery in some places to sort out why/what is going on. In this
particular
instance, I did override the source tag elements in question to
"normalize-space"
on their text() values (the tech writers said they had no expectation of
having
a line break in those markup tags) so I have worked around the issue.
However, it is our
estimation here that the file reader does have some odd corner cases that it
is getting tripped up on. ) Be curious to know if you agree/disagree on this
point.
Just to be really curious, does fop use some stock XML file parser (xalan?)
or
does it have its own?
That said, 0.94 does, so far, seem like an overall "win"
compared to a few things we were stuck with on 0.20.5 these past couple
years.
We've been waiting for "keeps" as our guides had orphaned section titles.
Dev's please keep up the good work!
Robert
-----Original Message-----
From: Andreas L Delmelle [mailto:a_l.delmelle@pandora.be]
Sent: Sunday, September 16, 2007 3:49 AM
To: fop-users@xmlgraphics.apache.org
Subject: Re: migrating to 0.94 for pdf output; getting
ArrayIndexOutOfBoun ds
On Sep 15, 2007, at 16:18, Andreas L Delmelle wrote:
Hello Robert
Had a closer look at your example, and I'm wondering whether you
really need to preserve the linefeeds and white-space characters in
the block in question... If you remove white-space-
treatment="preserve" and linefeed-treatment="preserve", the exception
can also be avoided. Can you check? If those properties are not
really necessary, then this would be the simplest way to sidestep the
issue. In the meantime, I'll check bugzilla, and will file it as a
bug once I succeed in determining the exact cause.
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: migrating to 0.94 for pdf output; getting ArrayIndexOutOfBoun ds
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Sep 17, 2007, at 22:06, Andreas L Delmelle wrote:
<snip />
> ... If you subsequently use FO properties like linefeed- and white-
> space-treatment, that may lead to strange cases, that are
> semantically 100% correct.
> BUT, even if FOP would not choke on it, chances are that the
> 'correct' treatment would not be what the average user would expect.
FWIW, see the attached (IMO 100% correct) PDF output when running the
original example through my locally patched FOP, which for the moment
simply avoids the error through a dirty hack.
ror.
Re: migrating to 0.94 for pdf output; getting ArrayIndexOutOfBoun ds
Posted by Lance Goforth <la...@arn.net>.
I recognize that error, I have seen it and fixed it before. However I
wasn't getting that error, just the array index error. Finding and fixing
that cell does prevent the error from occurring though. Thanks.
On 9/20/07, Andreas L Delmelle <a_...@pandora.be> wrote:
>
> On Sep 20, 2007, at 20:47, Lance Goforth wrote:
>
> > I haven't had much time to do any debugging, so for now I'm staying
> > with the older version. But this fo with the new version is the
> > one that gets the error.
>
> The error I get for this FO is unrelated to the one in the OP. In
> your case, the fix is in the error-message:
>
> org.apache.fop.fo.ValidationException: file:///users/andreas/
> documents/xml/2007-09-20.fo:1:5181:
> Error(1/5181): fo:table-cell is missing child elements.
> Required Content Model: marker* (%block;)+
>
> The only way to avoid this error, is to adapt the stylesheet to
> produce correct FO and at least generate an empty fo:block, or leave
> the fo:table-cell out entirely if it will contain nothing and you
> don't need the borders.
>
>
> Cheers
>
> Andreas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
Re: migrating to 0.94 for pdf output; getting ArrayIndexOutOfBoun ds
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Sep 20, 2007, at 20:47, Lance Goforth wrote:
> I haven't had much time to do any debugging, so for now I'm staying
> with the older version. But this fo with the new version is the
> one that gets the error.
The error I get for this FO is unrelated to the one in the OP. In
your case, the fix is in the error-message:
org.apache.fop.fo.ValidationException: file:///users/andreas/
documents/xml/2007-09-20.fo:1:5181:
Error(1/5181): fo:table-cell is missing child elements.
Required Content Model: marker* (%block;)+
The only way to avoid this error, is to adapt the stylesheet to
produce correct FO and at least generate an empty fo:block, or leave
the fo:table-cell out entirely if it will contain nothing and you
don't need the borders.
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: migrating to 0.94 for pdf output; getting ArrayIndexOutOfBoun ds
Posted by Lance Goforth <la...@arn.net>.
I haven't had much time to do any debugging, so for now I'm staying with the
older version. But this fo with the new version is the one that gets the
error.
On 9/20/07, Andreas L Delmelle <a_...@pandora.be> wrote:
>
> On Sep 20, 2007, at 19:51, Lance Goforth wrote:
>
> Hi
>
> > I am having the same error in several of my fo reports. I've tried
> > some of these suggestions, but they didn't help my issue either.
>
> Can you provide a sample of a FO causing the error on your end, so
> that we can have a closer look?
>
> TIA
>
> Andreas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
Re: migrating to 0.94 for pdf output; getting ArrayIndexOutOfBoun ds
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Sep 20, 2007, at 19:51, Lance Goforth wrote:
Hi
> I am having the same error in several of my fo reports. I've tried
> some of these suggestions, but they didn't help my issue either.
Can you provide a sample of a FO causing the error on your end, so
that we can have a closer look?
TIA
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: migrating to 0.94 for pdf output; getting ArrayIndexOutOfBoun ds
Posted by Lance Goforth <la...@arn.net>.
I am having the same error in several of my fo reports. I've tried some of
these suggestions, but they didn't help my issue either.
On 9/17/07, Andreas L Delmelle <a_...@pandora.be> wrote:
>
> On Sep 17, 2007, at 21:28, Andreas L Delmelle wrote:
>
> Sorry, realized that I expressed myself badly, so before anyone feels
> compelled to point out my mistake... ;-P
>
> > On Sep 17, 2007, at 15:33, Robert Lybarger wrote:
> >
> >> <snip />
> >> I did override the source tag elements in question to
> >> "normalize-space"
> >> on their text() values (the tech writers said they had no
> >> expectation of
> >> having
> >> a line break in those markup tags) so I have worked around the issue.
> >
> > That was going to be my next suggestion. :-)
> > Note that using a lot of <xsl:apply-templates /> (without selecting
> > any specific nodes/elements) will also virtually always cause
> > insertion of 'unexpected' linefeeds/spaces. This is because a
> > simple apply-templates processes *all* nodes in the source XML,
> > including white-space (due to the built-in template rule for text()).
>
> To express it better: a simple apply-templates picks up all text()
> nodes as well, entirely, so if you have an element:
>
> <test>
> a
>
> </test>
>
> The XPath "/test/text()" will correspond to one text() node,
> consisting of:
> - one linefeed
> - two spaces
> - a letter 'a'
> - another linefeed
> - two spaces
> - another linefeed
>
> Since the text also contains one non-white-space character, the
> surrounding spaces and linefeeds are not removed implicitly during
> the transform. You have to resort to normalize-space() to remove
> trailing and leading spaces.
> Otherwise, that entire text() node will be copied as-is to the result
> tree. If you subsequently use FO properties like linefeed- and white-
> space-treatment, that may lead to strange cases, that are
> semantically 100% correct.
> BUT, even if FOP would not choke on it, chances are that the
> 'correct' treatment would not be what the average user would expect.
>
>
> Cheers
>
> Andreas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
Re: migrating to 0.94 for pdf output; getting ArrayIndexOutOfBoun ds
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Sep 17, 2007, at 21:28, Andreas L Delmelle wrote:
Sorry, realized that I expressed myself badly, so before anyone feels
compelled to point out my mistake... ;-P
> On Sep 17, 2007, at 15:33, Robert Lybarger wrote:
>
>> <snip />
>> I did override the source tag elements in question to
>> "normalize-space"
>> on their text() values (the tech writers said they had no
>> expectation of
>> having
>> a line break in those markup tags) so I have worked around the issue.
>
> That was going to be my next suggestion. :-)
> Note that using a lot of <xsl:apply-templates /> (without selecting
> any specific nodes/elements) will also virtually always cause
> insertion of 'unexpected' linefeeds/spaces. This is because a
> simple apply-templates processes *all* nodes in the source XML,
> including white-space (due to the built-in template rule for text()).
To express it better: a simple apply-templates picks up all text()
nodes as well, entirely, so if you have an element:
<test>
a
</test>
The XPath "/test/text()" will correspond to one text() node,
consisting of:
- one linefeed
- two spaces
- a letter 'a'
- another linefeed
- two spaces
- another linefeed
Since the text also contains one non-white-space character, the
surrounding spaces and linefeeds are not removed implicitly during
the transform. You have to resort to normalize-space() to remove
trailing and leading spaces.
Otherwise, that entire text() node will be copied as-is to the result
tree. If you subsequently use FO properties like linefeed- and white-
space-treatment, that may lead to strange cases, that are
semantically 100% correct.
BUT, even if FOP would not choke on it, chances are that the
'correct' treatment would not be what the average user would expect.
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: migrating to 0.94 for pdf output; getting ArrayIndexOutOfBoun ds
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Sep 17, 2007, at 15:33, Robert Lybarger wrote:
> 1. An intermediate *.fo file is generated prior to being sent to
> FOP itself,
> yes.
> (PDF creation for us is a complex, multi-step process that requires
> this
> approach.
> At least as a side effect, I can trace intermediate files for
> problems.)
>
> 2. "indent mode" is turned off for the entire process -- turning it
> on tends
> to
> introduce whitespaces between words and punctuation where it is never
> wanted,
> so it's a rule/policy to only 'indent' for debugging purposes.
OK, so that can't be the problem...
> Our "XSLT" is basically an in-house modification of DITA toolkit (v
> 1.2?)
> which
> is rather spidery in some places to sort out why/what is going on.
> In this
> particular
> instance, I did override the source tag elements in question to
> "normalize-space"
> on their text() values (the tech writers said they had no
> expectation of
> having
> a line break in those markup tags) so I have worked around the issue.
That was going to be my next suggestion. :-)
Note that using a lot of <xsl:apply-templates /> (without selecting
any specific nodes/elements) will also virtually always cause
insertion of 'unexpected' linefeeds/spaces. This is because a simple
apply-templates processes *all* nodes in the source XML, including
white-space (due to the built-in template rule for text()).
> However, it is our estimation here that the file reader does have
> some odd corner cases that it
> is getting tripped up on. ) Be curious to know if you agree/
> disagree on this
> point.
I'll look at the example a bit more in detail. AFAICT, you have
definitely stumbled upon a corner case that currently is not handled
correctly (otherwise, the exception would not occur; there is nothing
wrong with having a linefeed there and preserving it, so if that was
actually necessary, you would be stuck)
> Just to be really curious, does fop use some stock XML file parser
> (xalan?)
> or does it have its own?
FOP normally uses whatever XML parser and XSLT processor you have
installed. We don't reference any specific implementation, but rely
entirely on JAXP.
Just in case a user has a JVM, but no XML parser or XSLT processor,
we also distribute the latest versions of Xerces-J and Xalan-J with FOP.
> That said, 0.94 does, so far, seem like an overall "win"
> compared to a few things we were stuck with on 0.20.5 these past
> couple
> years.
That's good to know. Thanks for the feedback.
Later,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org