Page 44 of the document in question has a few very complicated geometric paths containing more then 6000 points. For some reason Java runs out of memory when converting the geometric path to an area. The complex geometric path is used to clip graphics on the page which give a cut out effect.

Some time will have to spent to further understand why Java geom is having problems with this many data sets or type. It might be possible to divide the geometric shape in to smaller area's and then do an intersect of the areas and thus avoid the bottle neck of doing them all at once.

Hi Patrick, Is it possible for you to share how you went on debugging and identifying this issue. I have some spare time and can take a look. Just I am not aware of how to turn on the logs for ICE pdf.

This one is actually pretty hard to track down as the PDF content stream is big enough to cut out java.util.logging. I had to do some pausing and stepping with the debugger to figure out where the bottle neck was.

As mentioned earlier it is page 44 that causing the problem. There are several content streams the define the clipping area around the images on the page that produce the cutout effect. In theses content streams there are a large number of geometric operators that are added to our shapes stack when the 'w" token is encountered, this takes place in the ContentParser class. You can do a search for "PdfOps.W_TOKEN", this is where we handle geometric path that has been build up by previous PostScrip operands.

At the end of the PdfOps.W_TOKEN block, graphicState.setClip is called which is where things blow up. In the setClip method Area area = new Area(newClip); causes the out of memory error. I had fooled around with some code that would copy the newClip operands into smaller shapes but it turned out that the ContentPaser was spending an enormous amount of time just trying to process all the geometric path information.

I'm guessing there must be another way to handle Area area = new Area(newClip); and later transforms using a different combinations of java.awt.geom.

I guess there is a memory leak or poor handling code in Area area = new Area(newClip);
After increasing the heap space to -Xmx1024m , the processing went through but was very slow.

Also java community suggests not to use the slow Area whenever possible. So one of the solution would be to rewrite parts of the code using Area classes or live with it by increasing heap size and slowness.. Dont know what JDK alternatives are available for clipping.

The exception trace is below when heap size is default:
----------------------------------------------------------------------------------------
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at sun.awt.geom.AreaOp.resolveLinks(AreaOp.java:434)
at sun.awt.geom.AreaOp.pruneEdges(AreaOp.java:374)
at sun.awt.geom.AreaOp.calculate(AreaOp.java:141)
at java.awt.geom.Area.pathToCurves(Area.java:177)
at java.awt.geom.Area.<init>(Area.java:108)
at org.icepdf.core.pobjects.graphics.GraphicsState.setClip(GraphicsState.java:568)
at org.icepdf.core.util.ContentParser.parse(ContentParser.java:512)
at org.icepdf.core.pobjects.Page.init(Page.java:369)
at org.icepdf.core.pobjects.Page.paint(Page.java:449)
at org.icepdf.core.pobjects.Page.paint(Page.java:421)
at org.icepdf.core.pobjects.Page.paint(Page.java:402)
at org.icepdf.core.pobjects.Document.getPageImage(Document.java:1039)
at com.test.common.util.IcePdf2ImageUtil.pdfToImage(IcePdf2ImageUtil.java:79)
at com.test.common.util.IcePdf2ImageUtil.main(IcePdf2ImageUtil.java:29)
--------------------------------------------------------------------------------------------------------------

Thanks for posting your findings. I'll look into alternatives to using the Area class.

Closing do to inactivity and the likely hood we are looking at a JDK bug. Will open if requested by the client.