On 13 Jan 2010, at 21:27, Stephan Thesing wrote: Hi Stephan,
<snip /> > Since increasing the heap space does not always work (3 GB heap space was > required in one example), I need a better solution for this. > > 1. "-conserve" option > One alternative would be the "-conserve" option, which serializes the pages > to disk and reloads them as needed. > Although slow, this definitely would be a solution, if it worked, which it > doesn't: > Our documents include graphics (SVG, PNG), and the serialization with > "-conserve" throws an exception, because some class in Batik is not > serializable (e.g. "SVGOMAnimatedString" IIRR), thus the page is missing, > causing FOP to abort later. > Thus, Batik would have to be fixed for this. I think FOP can be 'fixed' for this too. If that is really the only class that is causing trouble, then FOP could make a serializable subclass for it, and use that in the area tree, instead of Batik's default non-serializable implementation. Unless Batik really needs it, why fix it there? It would require some thought on a (de)serialization routine, though... But seems much easier/faster to implement than the two-pass approach, if time/effort is of the essence. Regards, Andreas mailto:andreas.delmelle.AT.telenet.be ---
