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 DavidJKelly <dk...@scriptorium.com> on 2008/08/11 18:43:35 UTC
Java heap overflow error - unknown reason
I have been trying to troubleshoot a java heap error for a good while, and I
have researched the error messages on this site without luck. I have a
6000+ page document with numerous tables - the largest tables being at the
front of the document, where they run fine. In dividing the document, I
find that it gets to slightly over 3000 pages before it dies. Because the
tables are simple two-column tables, I tried setting them up as lists in
list-blocks, but I still get a similar error. Following are the errors from
both the table and list versions:
TABLE:
--- Nested Exception ---
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:2882)
at
java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390)
at java.lang.StringBuffer.append(StringBuffer.java:224)
at
org.apache.fop.layoutmgr.AbstractLayoutManager.addChildLM(AbstractLayoutManager.java:275)
at
org.apache.fop.layoutmgr.AbstractLayoutManager.addChildLMs(AbstractLayoutManager.java:289)
at
org.apache.fop.layoutmgr.BlockLayoutManager.createLineManager(BlockLayoutManager.java:205)
at
org.apache.fop.layoutmgr.BlockLayoutManager.createNextChildLMs(BlockLayoutManager.java:173)
at org.apache.fop.layoutmgr.LMiter.hasNext(LMiter.java:40)
at
org.apache.fop.layoutmgr.AbstractLayoutManager.getChildLM(AbstractLayoutManager.java:116)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getBreakBefore(BlockStackingLayoutManager.java:978)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.addKnuthElementsForBreakBefore(BlockStackingLayoutManager.java:954)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:253)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:116)
at
org.apache.fop.layoutmgr.table.TableCellLayoutManager.getNextKnuthElements(TableCellLayoutManager.java:170)
at
org.apache.fop.layoutmgr.table.RowGroupLayoutManager.createElementsForRowGroup(RowGroupLayoutManager.java:120)
at
org.apache.fop.layoutmgr.table.RowGroupLayoutManager.getNextKnuthElements(RowGroupLayoutManager.java:60)
at
org.apache.fop.layoutmgr.table.TableContentLayoutManager.getKnuthElementsForRowIterator(TableContentLayoutManager.java:220)
at
org.apache.fop.layoutmgr.table.TableContentLayoutManager.getNextKnuthElements(TableContentLayoutManager.java:172)
at
org.apache.fop.layoutmgr.table.TableLayoutManager.getNextKnuthElements(TableLayoutManager.java:247)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:294)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:116)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:294)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:116)
at
org.apache.fop.layoutmgr.StaticContentLayoutManager$StaticContentBreaker.getNextKnuthElements(StaticContentLayoutManager.java:318)
at
org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:552)
at
org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:302)
at
org.apache.fop.layoutmgr.StaticContentLayoutManager.doLayout(StaticContentLayoutManager.java:240)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager.layoutSideRegion(PageSequenceLayoutManager.java:156)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager.finishPage(PageSequenceLayoutManager.java:163)
at
org.apache.fop.layoutmgr.AbstractPageSequenceLayoutManager.makeNewPage(AbstractPageSequenceLayoutManager.java:284)
at
org.apache.fop.layoutmgr.PageBreaker.handleBreakTrait(PageBreaker.java:494)
LIST:
--- Nested Exception ---
java.lang.OutOfMemoryError: Java heap space
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
at java.lang.Class.getMethod0(Class.java:2670)
at java.lang.Class.getMethod(Class.java:1603)
at
org.apache.commons.logging.LogFactory.getContextClassLoader(LogFactory.java:438)
at org.apache.commons.logging.LogFactory$1.run(LogFactory.java:222)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:218)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351)
at
org.apache.fop.layoutmgr.inline.BasicScaledBaselineTable.<init>(BasicScaledBaselineTable.java:37)
at
org.apache.fop.layoutmgr.inline.ScaledBaselineTableFactory.makeFontScaledBaselineTable(ScaledBaselineTableFactory.java:44)
at
org.apache.fop.layoutmgr.inline.ScaledBaselineTableFactory.makeFontScaledBaselineTable(ScaledBaselineTableFactory.java:56)
at
org.apache.fop.layoutmgr.inline.AlignmentContext.<init>(AlignmentContext.java:179)
at
org.apache.fop.layoutmgr.inline.LineLayoutManager.getNextKnuthElements(LineLayoutManager.java:580)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:294)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:116)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:294)
at
org.apache.fop.layoutmgr.list.ListItemLayoutManager.getNextKnuthElements(ListItemLayoutManager.java:218)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:294)
at
org.apache.fop.layoutmgr.list.ListBlockLayoutManager.getNextKnuthElements(ListBlockLayoutManager.java:119)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:294)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:116)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:294)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:116)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:294)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:116)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:294)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:116)
at
org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:107)
at
org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.java:145)
at
org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:552)
at
org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:137)
Pertinent data: I'm using FOP 0.95 (started with 0.94 and had similar
errors) and jdk1.6.0_03. I've stripped out pretty much all attributes from
the fo: elements, but here's an example of a list:
<fo:list-block provisional-distance-between-starts="12pt"
provisional-label-separation="5pt" margin-left="36pt" start-indent="10pt">
<fo:list-item provisional-distance-between-starts="12pt"
provisional-label-separation="5pt" margin-left="36pt" start-indent="10pt">
<fo:list-item-label end-indent="label-end()">
<fo:block font-size="14pt">
<fo:inline>•</fo:inline>
</fo:block>
</fo:list-item-label>
<fo:list-item-body start-indent="body-start()">
<fo:block space-after="0pt"><fo:inline font-weight="bold">TEXT:
</fo:inline> and some more text. </fo:block>
</fo:list-item-body>
</fo:list-item>
<fo:list-item provisional-distance-between-starts="12pt"
provisional-label-separation="5pt" margin-left="36pt" start-indent="10pt">
<fo:list-item-label end-indent="label-end()">
<fo:block font-size="14pt">
<fo:inline>•</fo:inline>
</fo:block>
</fo:list-item-label>
<fo:list-item-body start-indent="body-start()">
<fo:block space-after="0pt">
<fo:inline font-weight="bold">TEXT: </fo:inline> More Text.
</fo:block>
</fo:list-item-body>
</fo:list-item>
</fo:list-block>
Any help would be most appreciated. Please let me know if additional
information would be helpful.
Regards,
David Kelly
--
View this message in context: http://www.nabble.com/Java-heap-overflow-error---unknown-reason-tp18929472p18929472.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Java heap overflow error - unknown reason
Posted by Luis Ferro <ki...@gmail.com>.
Nevertheless, if you can post the fo with gibberish it would be useful for
profiling purposes... (if sensitive, send it directly to the dev team and
not to the list).
There is always a lack of real world examples! And real world is always
giving us surprises.
;)
On Wed, Aug 13, 2008 at 1:40 PM, DavidJKelly <dk...@scriptorium.com> wrote:
>
> Hmm - I see now that although the environment variable I mentioned earlier
> had been set, that variable was not placed on the fop command line. I have
> corrected the problem and it now runs fine. My apologies for the
> misdirection, and thank you for the hint.
>
> Regards,
> David Kelly
>
>
>
> Are you actually giving FOP a little memory to play with? I mean a
> little more than the 64MB allocated by default? FOP is still a bit
> memory-intensive, but 100 pages (per page-sequence) should easily be
> handled with less than 512MB. If you can, post a link to an FO file.
> That would allow us to do some profiling to see why this happens (if my
> very obvious tip above doesn't apply).
>
>
> --
> View this message in context:
> http://www.nabble.com/Java-heap-overflow-error---unknown-reason-tp18929472p18962257.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
Re: Java heap overflow error - unknown reason
Posted by DavidJKelly <dk...@scriptorium.com>.
Hmm - I see now that although the environment variable I mentioned earlier
had been set, that variable was not placed on the fop command line. I have
corrected the problem and it now runs fine. My apologies for the
misdirection, and thank you for the hint.
Regards,
David Kelly
Are you actually giving FOP a little memory to play with? I mean a
little more than the 64MB allocated by default? FOP is still a bit
memory-intensive, but 100 pages (per page-sequence) should easily be
handled with less than 512MB. If you can, post a link to an FO file.
That would allow us to do some profiling to see why this happens (if my
very obvious tip above doesn't apply).
--
View this message in context: http://www.nabble.com/Java-heap-overflow-error---unknown-reason-tp18929472p18962257.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Java heap overflow error - unknown reason
Posted by DavidJKelly <dk...@scriptorium.com>.
We have this environment setting:
set FOP_OPTS=-Xmx999m %FOP_OPTS%
Then we run the fop command line.
To post the fo file I will need to replace the text with gibberish since it
is sensitive material. I will attempt to upload it later today.
David Kelly
Jeremias Maerki-2 wrote:
>
> Are you actually giving FOP a little memory to play with? I mean a
> little more than the 64MB allocated by default? FOP is still a bit
> memory-intensive, but 100 pages (per page-sequence) should easily be
> handled with less than 512MB. If you can, post a link to an FO file.
> That would allow us to do some profiling to see why this happens (if my
> very obvious tip above doesn't apply).
>
>
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Java-heap-overflow-error---unknown-reason-tp18929472p18961914.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Java heap overflow error - unknown reason
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Are you actually giving FOP a little memory to play with? I mean a
little more than the 64MB allocated by default? FOP is still a bit
memory-intensive, but 100 pages (per page-sequence) should easily be
handled with less than 512MB. If you can, post a link to an FO file.
That would allow us to do some profiling to see why this happens (if my
very obvious tip above doesn't apply).
On 12.08.2008 21:53:25 DavidJKelly wrote:
>
> Andreas,
>
> Most of the book was in fact in a single page sequence. I attempted the
> three fixes you suggested, but with no luck. The FO is now in page sequences
> less than 100 pages each, and all fo:inlines are now fo:wrappers. I have
> also removed all keep-together and keep-with attributes.
>
> At risk of repetition, here is the error I get:
>
> WARNING: Line 2 of a paragraph overflows the available area by 400mpt.
> (fo:block
> , location: 46211/114)
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
> at
> org.apache.fop.layoutmgr.inline.TextLayoutManager.createTextArea(Text
> LayoutManager.java:408)
> at
> org.apache.fop.layoutmgr.inline.TextLayoutManager.addAreas(TextLayout
> Manager.java:361)
> at
> org.apache.fop.layoutmgr.inline.LineLayoutManager.addInlineArea(LineL
> ayoutManager.java:1716)
> at
> org.apache.fop.layoutmgr.inline.LineLayoutManager.addAreas(LineLayout
> Manager.java:1568)
> at
> org.apache.fop.layoutmgr.BlockLayoutManager.addAreas(BlockLayoutManag
> er.java:395)
> at
> org.apache.fop.layoutmgr.BlockLayoutManager.addAreas(BlockLayoutManag
> er.java:395)
> at
> org.apache.fop.layoutmgr.BlockLayoutManager.addAreas(BlockLayoutManag
> er.java:395)
> at
> org.apache.fop.layoutmgr.BlockLayoutManager.addAreas(BlockLayoutManag
> er.java:395)
> at
> org.apache.fop.layoutmgr.AreaAdditionUtil.addAreas(AreaAdditionUtil.j
> ava:121)
> at
> org.apache.fop.layoutmgr.FlowLayoutManager.addAreas(FlowLayoutManager
> .java:305)
> at
> org.apache.fop.layoutmgr.PageBreaker.addAreas(PageBreaker.java:241)
> at
> org.apache.fop.layoutmgr.AbstractBreaker.addAreas(AbstractBreaker.jav
> a:508)
> at
> org.apache.fop.layoutmgr.AbstractBreaker.addAreas(AbstractBreaker.jav
> a:371)
> at
> org.apache.fop.layoutmgr.PageBreaker.doPhase3(PageBreaker.java:262)
> at
> org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.jav
> a:346)
> at
> org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.jav
> a:264)
> at
> org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(Pag
> eSequenceLayoutManager.java:106)
> at
> org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.j
> ava:234)
> at
> org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java
> :123)
> at
> org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilde
> r.java:340)
> at
> org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:169)
> at
> org.apache.xalan.transformer.TransformerIdentityImpl.endElement(Trans
> formerIdentityImpl.java:1101)
> at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
> Source
> )
> at org.apache.xerces.xinclude.XIncludeHandler.endElement(Unknown
> Source)
>
> at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknow
> n Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContent
> Dispatcher.dispatch(Unknown Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Un
> known 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.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown
> Sour
> ce)
>
> Many thanks for the quickness of your previous reply. Any further help you
> might be able to offer would be appreciated.
>
> Regards,
> David Kelly
>
>
>
> Andreas Delmelle-2 wrote:
> >
> > On Aug 11, 2008, at 18:43, DavidJKelly wrote:
> >
> > Hi
> >
> >> I have been trying to troubleshoot a java heap error for a good
> >> while, and I
> >> have researched the error messages on this site without luck. I
> >> have a
> >> 6000+ page document with numerous tables - the largest tables being
> >> at the
> >> front of the document, where they run fine. In dividing the
> >> document, I
> >> find that it gets to slightly over 3000 pages before it dies.
> >> Because the
> >> tables are simple two-column tables, I tried setting them up as
> >> lists in
> >> list-blocks, but I still get a similar error. Following are the
> >> errors from
> >> both the table and list versions:
> >
> > It depends on how large the individual page-sequences are. If you
> > cram all 6000 pages into one page-sequence, and do not use forced
> > breaks anywhere, you're going to need what looks like an unreasonable
> > amount of heap to render the document (because the current
> > implementation of the layout algorithm does not consider any page-
> > break final, unless in case of a forced break, or the end of the page-
> > sequence).
> >
> > If possible, try to break up the document into multiple page-
> > sequences, and the issue should disappear.
> >
> > Other hint: if the document contains a lot of fo:inlines, try simply
> > replacing those with fo:wrapper.
> >
> >
> > Cheers
> >
> > Andreas
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Java-heap-overflow-error---unknown-reason-tp18929472p18951490.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: Problem with table formatting
Posted by Brian Trezise <Br...@IntelliData.net>.
That got it, thanks :)
___________________________________________________
Brian Trezise
Staff Software Engineer
IntelliData, Inc
22288 E Princeton Dr
aurora, colorado 80018
T: 720.524.4864
brian.trezise@intellidata.net
-----Original Message-----
From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
Sent: Tuesday, August 12, 2008 2:48 PM
To: fop-users@xmlgraphics.apache.org
Subject: Re: Problem with table formatting
The problem here is property inheritance. You're specifying a
margin-left="160pt" on a block. That margin is internally mapped to
start-indent which is an inherited property. It will be propagated into
the fo:table-cell. And because fo:table-cell produces a so-called
reference-area, the space available for text is restricted by 160pt. In
your particular case you end up with a negative available width (150pt -
160pt = -10pt) inside the table-cell. That's why FOP breaks after every
word. I know this sounds weird but it's the way XSL-FO works.
The full details can be found here if you're interested:
http://wiki.apache.org/xmlgraphics-fop/IndentInheritance
Executive summary and work-around:
Just set start-indent="0pt" and end-indent="0pt" on the fo:table-body.
On 12.08.2008 22:07:11 Brian Trezise wrote:
> I'm having a problem formatting table cells where FOP wants to wrap lines
> for every word in the cell, even though there is plenty of room for the
> entire contents of the cell without line wrapping.
>
> I'm building a fo:table as follows:
>
> <fo-snippet>
>
> <fo:block-container absolute-position='fixed'>
> <fo:block margin-top='340pt' margin-left='325pt' font-weight='bold'
> font-size='12pt'>
> <xsl:value-of select='part/spec-data/caption'/>
> </fo:block>
> </fo:block-container>
>
> <fo:block-container absolute-position='fixed'>
> <fo:block margin-top='365pt' margin-left='160pt' text-align='left'>
> <fo:table>
> <fo:table-column column-width='150pt'/>
> <fo:table-column column-width='150pt'/>
> <fo:table-body>
> <xsl:for-each select="part/spec-data/row">
> <fo:table-row>
> <fo:table-cell>
> <fo:block
> font-size='8pt' font-weight='bold'>
>
> <xsl:value-of select='table-header'/>:
> </fo:block>
> </fo:table-cell>
> <fo:table-cell>
> <fo:block
> font-size='8pt'>
>
> <xsl:value-of select='table-data'/>
> </fo:block>
> </fo:table-cell>
> </fo:table-row>
> </xsl:for-each>
> </fo:table-body>
> </fo:table>
> </fo:block>
> </fo:block-container>
>
> </fo-snippet>
>
> However, when I run fop on this table, I am getting the word wrapping (see
> attachment for screenshot). Can somebody tell me what I'm doing wrong
here?
>
> Thanks,
> ___________________________________________________
> Brian Trezise
> Staff Software Engineer
> IntelliData, Inc
> 22288 E Princeton Dr
> aurora, colorado 80018
> T: 720.524.4864
> brian.trezise@intellidata.net
Jeremias Maerki
---------------------------------------------------------------------
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: Problem with table formatting
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
The problem here is property inheritance. You're specifying a
margin-left="160pt" on a block. That margin is internally mapped to
start-indent which is an inherited property. It will be propagated into
the fo:table-cell. And because fo:table-cell produces a so-called
reference-area, the space available for text is restricted by 160pt. In
your particular case you end up with a negative available width (150pt -
160pt = -10pt) inside the table-cell. That's why FOP breaks after every
word. I know this sounds weird but it's the way XSL-FO works.
The full details can be found here if you're interested:
http://wiki.apache.org/xmlgraphics-fop/IndentInheritance
Executive summary and work-around:
Just set start-indent="0pt" and end-indent="0pt" on the fo:table-body.
On 12.08.2008 22:07:11 Brian Trezise wrote:
> I'm having a problem formatting table cells where FOP wants to wrap lines
> for every word in the cell, even though there is plenty of room for the
> entire contents of the cell without line wrapping.
>
> I'm building a fo:table as follows:
>
> <fo-snippet>
>
> <fo:block-container absolute-position='fixed'>
> <fo:block margin-top='340pt' margin-left='325pt' font-weight='bold'
> font-size='12pt'>
> <xsl:value-of select='part/spec-data/caption'/>
> </fo:block>
> </fo:block-container>
>
> <fo:block-container absolute-position='fixed'>
> <fo:block margin-top='365pt' margin-left='160pt' text-align='left'>
> <fo:table>
> <fo:table-column column-width='150pt'/>
> <fo:table-column column-width='150pt'/>
> <fo:table-body>
> <xsl:for-each select="part/spec-data/row">
> <fo:table-row>
> <fo:table-cell>
> <fo:block
> font-size='8pt' font-weight='bold'>
>
> <xsl:value-of select='table-header'/>:
> </fo:block>
> </fo:table-cell>
> <fo:table-cell>
> <fo:block
> font-size='8pt'>
>
> <xsl:value-of select='table-data'/>
> </fo:block>
> </fo:table-cell>
> </fo:table-row>
> </xsl:for-each>
> </fo:table-body>
> </fo:table>
> </fo:block>
> </fo:block-container>
>
> </fo-snippet>
>
> However, when I run fop on this table, I am getting the word wrapping (see
> attachment for screenshot). Can somebody tell me what I'm doing wrong here?
>
> Thanks,
> ___________________________________________________
> Brian Trezise
> Staff Software Engineer
> IntelliData, Inc
> 22288 E Princeton Dr
> aurora, colorado 80018
> T: 720.524.4864
> brian.trezise@intellidata.net
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: Problem with table formatting
Posted by Brian Trezise <Br...@IntelliData.net>.
Ok, got it. The table in question is at the bottom.
___________________________________________________
Brian Trezise
Staff Software Engineer
IntelliData, Inc
22288 E Princeton Dr
aurora, colorado 80018
T: 720.524.4864
brian.trezise@intellidata.net
From: David Gerdt [mailto:Dgerdt@bju.edu]
Sent: Tuesday, August 12, 2008 2:29 PM
To: fop-users@xmlgraphics.apache.org
Subject: Re: Problem with table formatting
This looks like a snippet from your XSL. Can you provide a sample of the
actual *FO* file produced when your transform is run? Without the associated
XML, we can't render the snippet you provide.
>>> "Brian Trezise" <Br...@IntelliData.net> 8/12/2008 4:07 PM >>>
I'm having a problem formatting table cells where FOP wants to wrap lines
for every word in the cell, even though there is plenty of room for the
entire contents of the cell without line wrapping.
I'm building a fo:table as follows:
<fo-snippet>
<fo:block-container absolute-position='fixed'>
<fo:block margin-top='340pt' margin-left='325pt' font-weight='bold'
font-size='12pt'>
<xsl:value-of select='part/spec-data/caption'/>
</fo:block>
</fo:block-container>
<fo:block-container absolute-position='fixed'>
<fo:block margin-top='365pt' margin-left='160pt' text-align='left'>
<fo:table>
<fo:table-column column-width='150pt'/>
<fo:table-column column-width='150pt'/>
<fo:table-body>
<xsl:for-each select="part/spec-data/row">
<fo:table-row>
<fo:table-cell>
<fo:block
font-size='8pt' font-weight='bold'>
<xsl:value-of select='table-header'/>:
</fo:block>
</fo:table-cell>
<fo:table-cell>
<fo:block
font-size='8pt'>
<xsl:value-of select='table-data'/>
</fo:block>
</fo:table-cell>
</fo:table-row>
</xsl:for-each>
</fo:table-body>
</fo:table>
</fo:block>
</fo:block-container>
</fo-snippet>
However, when I run fop on this table, I am getting the word wrapping (see
attachment for screenshot). Can somebody tell me what I'm doing wrong here?
Thanks,
___________________________________________________
Brian Trezise
Staff Software Engineer
IntelliData, Inc
22288 E Princeton Dr
aurora, colorado 80018
T: 720.524.4864
brian.trezise@intellidata.net
Re: Problem with table formatting
Posted by David Gerdt <Dg...@bju.edu>.
This looks like a snippet from your XSL. Can you provide a sample of the actual *FO* file produced when your transform is run? Without the associated XML, we can't render the snippet you provide.
>>> "Brian Trezise" <Br...@IntelliData.net> 8/12/2008 4:07 PM >>>
I'm having a problem formatting table cells where FOP wants to wrap lines
for every word in the cell, even though there is plenty of room for the
entire contents of the cell without line wrapping.
I'm building a fo:table as follows:
<fo-snippet>
<fo:block-container absolute-position='fixed'>
<fo:block margin-top='340pt' margin-left='325pt' font-weight='bold'
font-size='12pt'>
<xsl:value-of select='part/spec-data/caption'/>
</fo:block>
</fo:block-container>
<fo:block-container absolute-position='fixed'>
<fo:block margin-top='365pt' margin-left='160pt' text-align='left'>
<fo:table>
<fo:table-column column-width='150pt'/>
<fo:table-column column-width='150pt'/>
<fo:table-body>
<xsl:for-each select="part/spec-data/row">
<fo:table-row>
<fo:table-cell>
<fo:block
font-size='8pt' font-weight='bold'>
<xsl:value-of select='table-header'/>:
</fo:block>
</fo:table-cell>
<fo:table-cell>
<fo:block
font-size='8pt'>
<xsl:value-of select='table-data'/>
</fo:block>
</fo:table-cell>
</fo:table-row>
</xsl:for-each>
</fo:table-body>
</fo:table>
</fo:block>
</fo:block-container>
</fo-snippet>
However, when I run fop on this table, I am getting the word wrapping (see
attachment for screenshot). Can somebody tell me what I'm doing wrong here?
Thanks,
___________________________________________________
Brian Trezise
Staff Software Engineer
IntelliData, Inc
22288 E Princeton Dr
aurora, colorado 80018
T: 720.524.4864
brian.trezise@intellidata.net
Problem with table formatting
Posted by Brian Trezise <Br...@IntelliData.net>.
I'm having a problem formatting table cells where FOP wants to wrap lines
for every word in the cell, even though there is plenty of room for the
entire contents of the cell without line wrapping.
I'm building a fo:table as follows:
<fo-snippet>
<fo:block-container absolute-position='fixed'>
<fo:block margin-top='340pt' margin-left='325pt' font-weight='bold'
font-size='12pt'>
<xsl:value-of select='part/spec-data/caption'/>
</fo:block>
</fo:block-container>
<fo:block-container absolute-position='fixed'>
<fo:block margin-top='365pt' margin-left='160pt' text-align='left'>
<fo:table>
<fo:table-column column-width='150pt'/>
<fo:table-column column-width='150pt'/>
<fo:table-body>
<xsl:for-each select="part/spec-data/row">
<fo:table-row>
<fo:table-cell>
<fo:block
font-size='8pt' font-weight='bold'>
<xsl:value-of select='table-header'/>:
</fo:block>
</fo:table-cell>
<fo:table-cell>
<fo:block
font-size='8pt'>
<xsl:value-of select='table-data'/>
</fo:block>
</fo:table-cell>
</fo:table-row>
</xsl:for-each>
</fo:table-body>
</fo:table>
</fo:block>
</fo:block-container>
</fo-snippet>
However, when I run fop on this table, I am getting the word wrapping (see
attachment for screenshot). Can somebody tell me what I'm doing wrong here?
Thanks,
___________________________________________________
Brian Trezise
Staff Software Engineer
IntelliData, Inc
22288 E Princeton Dr
aurora, colorado 80018
T: 720.524.4864
brian.trezise@intellidata.net
Re: Java heap overflow error - unknown reason
Posted by DavidJKelly <dk...@scriptorium.com>.
Andreas,
Most of the book was in fact in a single page sequence. I attempted the
three fixes you suggested, but with no luck. The FO is now in page sequences
less than 100 pages each, and all fo:inlines are now fo:wrappers. I have
also removed all keep-together and keep-with attributes.
At risk of repetition, here is the error I get:
WARNING: Line 2 of a paragraph overflows the available area by 400mpt.
(fo:block
, location: 46211/114)
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at
org.apache.fop.layoutmgr.inline.TextLayoutManager.createTextArea(Text
LayoutManager.java:408)
at
org.apache.fop.layoutmgr.inline.TextLayoutManager.addAreas(TextLayout
Manager.java:361)
at
org.apache.fop.layoutmgr.inline.LineLayoutManager.addInlineArea(LineL
ayoutManager.java:1716)
at
org.apache.fop.layoutmgr.inline.LineLayoutManager.addAreas(LineLayout
Manager.java:1568)
at
org.apache.fop.layoutmgr.BlockLayoutManager.addAreas(BlockLayoutManag
er.java:395)
at
org.apache.fop.layoutmgr.BlockLayoutManager.addAreas(BlockLayoutManag
er.java:395)
at
org.apache.fop.layoutmgr.BlockLayoutManager.addAreas(BlockLayoutManag
er.java:395)
at
org.apache.fop.layoutmgr.BlockLayoutManager.addAreas(BlockLayoutManag
er.java:395)
at
org.apache.fop.layoutmgr.AreaAdditionUtil.addAreas(AreaAdditionUtil.j
ava:121)
at
org.apache.fop.layoutmgr.FlowLayoutManager.addAreas(FlowLayoutManager
.java:305)
at
org.apache.fop.layoutmgr.PageBreaker.addAreas(PageBreaker.java:241)
at
org.apache.fop.layoutmgr.AbstractBreaker.addAreas(AbstractBreaker.jav
a:508)
at
org.apache.fop.layoutmgr.AbstractBreaker.addAreas(AbstractBreaker.jav
a:371)
at
org.apache.fop.layoutmgr.PageBreaker.doPhase3(PageBreaker.java:262)
at
org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.jav
a:346)
at
org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.jav
a:264)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(Pag
eSequenceLayoutManager.java:106)
at
org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.j
ava:234)
at
org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java
:123)
at
org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilde
r.java:340)
at
org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:169)
at
org.apache.xalan.transformer.TransformerIdentityImpl.endElement(Trans
formerIdentityImpl.java:1101)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
Source
)
at org.apache.xerces.xinclude.XIncludeHandler.endElement(Unknown
Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknow
n Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContent
Dispatcher.dispatch(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Un
known 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.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown
Sour
ce)
Many thanks for the quickness of your previous reply. Any further help you
might be able to offer would be appreciated.
Regards,
David Kelly
Andreas Delmelle-2 wrote:
>
> On Aug 11, 2008, at 18:43, DavidJKelly wrote:
>
> Hi
>
>> I have been trying to troubleshoot a java heap error for a good
>> while, and I
>> have researched the error messages on this site without luck. I
>> have a
>> 6000+ page document with numerous tables - the largest tables being
>> at the
>> front of the document, where they run fine. In dividing the
>> document, I
>> find that it gets to slightly over 3000 pages before it dies.
>> Because the
>> tables are simple two-column tables, I tried setting them up as
>> lists in
>> list-blocks, but I still get a similar error. Following are the
>> errors from
>> both the table and list versions:
>
> It depends on how large the individual page-sequences are. If you
> cram all 6000 pages into one page-sequence, and do not use forced
> breaks anywhere, you're going to need what looks like an unreasonable
> amount of heap to render the document (because the current
> implementation of the layout algorithm does not consider any page-
> break final, unless in case of a forced break, or the end of the page-
> sequence).
>
> If possible, try to break up the document into multiple page-
> sequences, and the issue should disappear.
>
> Other hint: if the document contains a lot of fo:inlines, try simply
> replacing those with fo:wrapper.
>
>
> Cheers
>
> Andreas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Java-heap-overflow-error---unknown-reason-tp18929472p18951490.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Java heap overflow error - unknown reason
Posted by Andreas Delmelle <an...@telenet.be>.
On Aug 11, 2008, at 18:43, DavidJKelly wrote:
Hi
> I have been trying to troubleshoot a java heap error for a good
> while, and I
> have researched the error messages on this site without luck. I
> have a
> 6000+ page document with numerous tables - the largest tables being
> at the
> front of the document, where they run fine. In dividing the
> document, I
> find that it gets to slightly over 3000 pages before it dies.
> Because the
> tables are simple two-column tables, I tried setting them up as
> lists in
> list-blocks, but I still get a similar error. Following are the
> errors from
> both the table and list versions:
It depends on how large the individual page-sequences are. If you
cram all 6000 pages into one page-sequence, and do not use forced
breaks anywhere, you're going to need what looks like an unreasonable
amount of heap to render the document (because the current
implementation of the layout algorithm does not consider any page-
break final, unless in case of a forced break, or the end of the page-
sequence).
If possible, try to break up the document into multiple page-
sequences, and the issue should disappear.
Other hint: if the document contains a lot of fo:inlines, try simply
replacing those with fo:wrapper.
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org