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 
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.



Andreas Delmelle

Reply via email to