What I could find on int[] references seems to be...
org.apache.fop.render.pdf.PDFRenderer extends
AbstractPathOrientedRenderer implements PDFConfigurationConstants

 

org.apache.fop.render.bitmap.PNGRenderer extends Java2DRenderer

 

org.apache.fop.render.java2d.Java2DRenderer extends
AbstractPathOrientedRenderer implements Printable

int[] references:

public static void renderText(TextArea text, Graphics2D g2d, Font font)

private static int[] getGlyphOffsets(String s, Font font, TextArea text,
int[] letterAdjust)

 

Could this be because I'm loading in custom fonts?

Is this a bug in the Java2DRenderer?  A simple workaround?


________________________________

From: Peter Hancock [mailto:peter.hanc...@gmail.com] 
Sent: Wednesday, May 18, 2011 12:05 PM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Fop Memory Use


Hi Eric,

Does your document contain many large SVG's?  If so take a look at
Bugzilla #46360.  This issue was resolved in rev 997602 of FOP trunk.

Pete





On Wed, May 18, 2011 at 5:10 PM, Adrian Cumiskey
<adrian.cumis...@gmail.com> wrote:


        Hi Eric,

        Fop calculates layout in page sequence chunks, so try breaking
up your pages into chunks of page sequences.  Pages should be available
for garbage collection once the page sequence has been rendered.

        Cheers, Adrian.

        On May 18, 2011, at 7:24 AM, Michael Rubin
<mru...@thunderhead.com> wrote:
        
        

                Just a wild thought. But is there a way you could
possibly get the JVM to garbage collect between each run? Maybe that
might free the memory up?
                
                Thanks.
                
                -Mike
                
                On 18/05/11 13:20, Eric Douglas wrote: 

                        I am using Fop 1.0. 
                        I tried using Fop to transform a single
document.  When I got a little over 100 pages my FO file was over 5 MB.
The transform crashed with a Java heap out of memory error.

                        I managed to break the input down, as I'm using
embedded code generating the input programmatically, and the PDF output
is a lot smaller.

                        So I'm currently transforming 10 pages at a
time, setting the initial-page-number to the next sequence (1, 11, 21,
etc).

                        Then I save all the generated PDFs in memory and
merge them using pdfbox.  So far this is working great. 

                        I tried to do the same thing with the
PNGRenderer, just calling a method to transform 10 pages at a time and
save the output images in an array.

                        The PNGRenderer is created locally in the
method.  It should be getting released when the method ends but the java
process never releases any memory.

                        I tested a 90 page report and the memory use was
over 1 GB.  I tested on another machine where the memory limit is
apparently lower and it crashed on page 24.

                        Everything about the method to render to PNG is
the same as the method to render to PDF aside from the Renderer. 
                        Is there a problem with this renderer or
something I could need to do different? 


                


                                
Michael Rubin

Developer

Thunderhead Logo         Tagline         Triangles      
 T

 F

 M

 E

 W

+44 20 8238 7400 

+44 20 8238 7401 

 

<mailto:mru...@thunderhead.com> mru...@thunderhead.com 

www.thunderhead.com <http://www.thunderhead.com>   

Thunderhead featured in The Sunday Times Profit Track 100 league table
of companies with fastest-growing profits. Click here
<http://www.fasttrack.co.uk/fasttrack/press/pt11-lon.pdf>  to read more.


LinkedIn <http://www.linkedin.com/companies/25033/Thunderhead>  twitter
<http://twitter.com/Thunderheadon> RSS
<http://www.thunderhead.com/rss/rss.php> YouTube
<http://www.youtube.com/user/ThunderheadOn>
<http://thunderheadinnovate.wordpress.com/>  were-hiring
<http://thunderhead.com/about/careers.php>      
The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the
named addressee or an authorized designee, you may not copy or use it,
or disclose it to anyone else. If you received it in error please notify
us immediately and then destroy it.

                

                

                


Reply via email to