Jörg, remember this thread on fop-users? I've just found out what's wrong.
There's absolutely nothing wrong with the PDFRenderer or the PDF library concerning reference freeing. It does it so as soon as each image is written to the PDF which always happens immediately. But I found that org.apache.fop.fo.flow.ExternalGraphic unnecessarily maintains a hard reference on a FopImage. Unnecessarily, because we just need the instrinsic size there. The FopImage is never reset to null after use. I fixed that and: d'oh, still not good. I ended up in the image cache and in the Javadocs for WeakHashMap where I found that little detail that the weak reference is on the key, not the value. And the key is the URL (String) which is passed around in FOP. Ok, so I changed the WeakHashMap to a HashMap and wrapped the values in WeakReferences. Tadaaa! A PDF with 182 JPEG images with a total size of 258 MB is suddenly produced without exceptions using the VM's default heap settings, never going beyond 26MB heap usage. *g* Will test some more and then commit later. On 21.06.2006 23:03:38 J.Pietschmann wrote: > Jeremias Maerki wrote: > > Ouch, that could explain it. No, no changes in that area. Actually, > > images could be written to the file immediately and then released > > instead of having to wait until the next page-sequence is finished. > > While the image data is written as soon as possible, the XObject > which also points to the image object is kept for the object dictionary > which is written much later. There have been changes in the way the > object dictionaries are written to the PDF which I didn't track. > > > Should be easy to fix. > > Unfortunately, the XObject seems to query some data from the image > object while writing the dictionary. Jeremias Maerki
