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.




Reply via email to