Re: FOP and large documents: out of memory

[Stephan Thesing <th...@gmx.de>]

Hi Andreas,

-------- Original-Nachricht --------
> Datum: Wed, 13 Jan 2010 21:42:51 +0100
> Von: Andreas Delmelle <an...@telenet.be>
> An: fop-dev@xmlgraphics.apache.org
> Betreff: Re: FOP and large documents: out of memory

> 
> On 13 Jan 2010, at 21:27, Stephan Thesing wrote:
...
> > 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?

I don't think that can work, as that class is used in elements nested in classes of Batik that represent the SVG.

I.e., FOP never instantiates it, but the Batik code does somewhere along
the way of creating the SVG element that is actually used in the Area tree....
(I am not sure, if it is the only class that cannot be serialized, as the serialization is aborted as soon as the first non-serializable class is encountered.)

Best regards
   Stephan


-- 
Dr.-Ing. Stephan Thesing
Elektrastr. 50
81925 München
GERMANY

Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

Re: FOP and large documents: out of memory

[Andreas Delmelle <an...@telenet.be>]

On 13 Jan 2010, at 22:37, Stephan Thesing wrote:

>> 
>> On 13 Jan 2010, at 21:27, Stephan Thesing wrote:
> ...
>>> 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?
> 
> I don't think that can work, as that class is used in elements nested in classes of Batik that represent the SVG.
> 
> I.e., FOP never instantiates it, but the Batik code does somewhere along

OK, I see...

Just noticed that my idea for 'subclassing' is probably not entirely what I meant...
Suppose, for the sake of the argument, that String is not serializable, but we'd need it for some reason and the Java vendor does not want to alter their implementation. What could be done, is store only the info needed to create a new String upon deserialization. Serialize the char-array, and re-instantiate the String instead.

I was thinking something similar should be possible here, but if it is really that far out of FOP's control, then never mind.


Regards

Andreas

Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
---