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/13 22:35:58 UTC
RE: migrating to 0.94 for pdf output; getting ArrayIndexOutOfBoun
ds
Managed to whittle things down quite a bit. Looks like FOP throws the AIOOB
under a rather unique structure of the input file. Thought it might just be
nested fo:inline with a line break or couple in the middle, but that alone
isn't enough to trigger the problem. In the attached *.fo file, the xpath
location into the offending location looks like:
fo:root/fo:page-sequence/fo:flow/fo:block[2]/fo:list-block/fo:list-item/
[...cont...]
fo:list-item-body/fo:block/fo:block[2]/fo:block/fo:inline/fo:inline
Search there for a comment that says:
<!-- insert line break before comment for AIOOB exception -->
Adding a line-break at this location causes the problem, and the upstream
XML source and stylesheets generate an *.fo file that has a line break at
this location. While I /may/ can get the tech writers to fix this one
instance by removing an explicit line break in the source XML, it seems like
the *.fo file reader is really at fault here. (I also had a problem couple
days ago where my TOC page-number-citation numbers were not properly aligned
until I manually *added* line breaks to the *.fo file, so there's definitely
a behavioral difference that depends on the presence/absence of line
breaks.)
Files attached. Further platform details/environment settings/stacktraces
are all in my previous message.
Any comments?
-ROB-
-----Original Message-----
From: Robert Lybarger [mailto:roblyb@auto-trol.com]
Sent: Thursday, September 13, 2007 9:24 AM
To: 'fop-users@xmlgraphics.apache.org'
Subject: migrating to 0.94 for pdf output; getting ArrayIndexOutOfBounds
Hi all:
I manage a documentation build system that has, thus far, used 0.20.5 to
generate PDF files. I've been experimenting with 0.94 (jdk1.4 binary build)
over the past couple days smoothing out issues in our fo-generating
stylesheets one step upstream of FOP. Anyway, I just tried one of our larger
'mission critical' (heh) guides and I got the below exception. (That's with
"-d" turned on.) Any clues what might cause that? I'm willing to admit our
*.fo file might not be up to the spec fop-0.94 wants, but I've got no clues
below to know where to look. The rendered guide (in PDF form) is in the
neighborhood of 400 pages; playing divide-and-conquer won't be fun. Our
environment is win2000 and JDK1.6.0_02, and I have JAVA_OPTS set to
-Xmx512m. I also didn't see anything directly related in the open-bugzilla
area. (The only other AIOOB was for PCL output mode -- not what I'm doing.)
To be fair, there is a couple screenfuls of WARNINGs of the variety:
line 1 of a paragraph overflows available area
table-layout="fixed" and column-width unspecified => falling back to
proportional-column-width(1)
and there is one "SEVERE" for image not available (it's a relative path on
the local system to a jpg image... I'd have to ask the tech writers about
whether its a bogus reference or the image just got lost in the system)
Hopefully someone can point me forward here.
-ROB-
===console output begins===
Sep 13, 2007 8:58:24 AM org.apache.fop.cli.Main startFOP
SEVERE: Exception
java.lang.ArrayIndexOutOfBoundsException: -1
at
org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:168)
at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115)
at org.apache.fop.cli.Main.startFOP(Main.java:166)
at org.apache.fop.cli.Main.main(Main.java:197)
---------
java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.get(ArrayList.java:324)
at
org.apache.fop.layoutmgr.inline.TextLayoutManager.addALetterSpaceTo(TextLayo
utManager.java:807)
at
org.apache.fop.layoutmgr.inline.InlineStackingLayoutManager.addALetterSpaceT
o(InlineStackingLayoutManager.jav
a:301)
at
org.apache.fop.layoutmgr.InlineKnuthSequence.addALetterSpace(InlineKnuthSequ
ence.java:141)
at
org.apache.fop.layoutmgr.InlineKnuthSequence.appendSequence(InlineKnuthSeque
nce.java:80)
at
org.apache.fop.layoutmgr.KnuthSequence.appendSequenceOrClose(KnuthSequence.j
ava:91)
at
org.apache.fop.layoutmgr.inline.InlineLayoutManager.getNextKnuthElements(Inl
ineLayoutManager.java:323)
at
org.apache.fop.layoutmgr.inline.LineLayoutManager.collectInlineKnuthElements
(LineLayoutManager.java:654)
at
org.apache.fop.layoutmgr.inline.LineLayoutManager.getNextKnuthElements(LineL
ayoutManager.java:590)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(Blo
ckStackingLayoutManager.java:284)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayout
Manager.java:113)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(Blo
ckStackingLayoutManager.java:284)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayout
Manager.java:113)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(Blo
ckStackingLayoutManager.java:284)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayout
Manager.java:113)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(Blo
ckStackingLayoutManager.java:284)
at
org.apache.fop.layoutmgr.list.ListItemLayoutManager.getNextKnuthElements(Lis
tItemLayoutManager.java:229)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(Blo
ckStackingLayoutManager.java:284)
at
org.apache.fop.layoutmgr.list.ListBlockLayoutManager.getNextKnuthElements(Li
stBlockLayoutManager.java:119)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(Blo
ckStackingLayoutManager.java:284)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayout
Manager.java:113)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(Blo
ckStackingLayoutManager.java:284)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayout
Manager.java:113)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(Blo
ckStackingLayoutManager.java:284)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayout
Manager.java:113)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(Blo
ckStackingLayoutManager.java:284)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayout
Manager.java:113)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(Blo
ckStackingLayoutManager.java:284)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayout
Manager.java:113)
at
org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutMa
nager.java:106)
at
org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.java:1
45)
at
org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.ja
va:551)
at
org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:137)
at
org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:301)
at
org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:263)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequen
ceLayoutManager.java:144)
at
org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:233
)
at
org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:145)
at
org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:
378)
at
org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:194)
at
org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerI
dentityImpl.java:1101)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatc
her.dispatch(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at
org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerId
entityImpl.java:484)
at
org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:165)
at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115)
at org.apache.fop.cli.Main.startFOP(Main.java:166)
at org.apache.fop.cli.Main.main(Main.java:197)
---------------------------------------------------------------------
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 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
Re: migrating to 0.94 for pdf output; getting ArrayIndexOutOfBoun ds
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Sep 13, 2007, at 22:35, Robert Lybarger wrote:
Hi
Sorry for the delay...
> Managed to whittle things down quite a bit. Looks like FOP throws
> the AIOOB
> under a rather unique structure of the input file. Thought it might
> just be
> nested fo:inline with a line break or couple in the middle, but
> that alone
> isn't enough to trigger the problem. In the attached *.fo file, the
> xpath
> location into the offending location looks like:
>
> fo:root/fo:page-sequence/fo:flow/fo:block[2]/fo:list-block/fo:list-
> item/
> [...cont...]
> fo:list-item-body/fo:block/fo:block[2]/fo:block/fo:inline/fo:inline
>
> Search there for a comment that says:
> <!-- insert line break before comment for AIOOB exception -->
>
> Adding a line-break at this location causes the problem, and the
> upstream
> XML source and stylesheets generate an *.fo file that has a line
> break at
> this location. While I /may/ can get the tech writers to fix this one
> instance by removing an explicit line break in the source XML, it
> seems like
> the *.fo file reader is really at fault here.
When you say "*.fo file", do you mean that the FO output is
intermediately saved to a physical file, which is then fed to FOP?
In that case, the added linefeed could be caused by an <xsl:output
indent="yes" .../> in the stylesheet. I estimate it as highly
probable that you have one of these in the stylesheet, since the FO
is so neatly formatted (?)
If this is so, remember that, as a rule of thumb, indent="yes" should
not be used unless the resulting FO is meant to be human-readable
(i.e. for debugging purposes).
Another way to avoid that attribute from having the undesired effect
is to switch to direct XML+XSLT input.
Either do not save the FO-file physically at all and pass both the
semantic XML and the stylesheet to FOP, or apply an (almost) identity
transform on the saved FO file and strip the undesired white-space
before feeding it to FOP.
Admittedly, the way in which FOP deals with the situation definitely
needs to be improved, but I hope the above gave you some clues for
quite straightforward workarounds.
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org