I'm against removing clearCaches() at this time. It's like removing the
strokeText setting in the PDF Transcoder that would have been helpful in
some situations after it was removed. Yes, clearCaches() should not be
necessary today but as a last resort it is useful to have around.

Do I understand this correctly, that the NPE happens despite the call to
clearCaches()? If that is so, it is certainly a bug or another thread
might already have added a decoded PNG to the cache. The easiest
work-around is to use a different FopFactory for RTF and for PDF output
because then you'll have two different caches. That wouldn't have been
possible prior to the API redesign.

Anyway, the root of the problem here is, surprise, the image library
which is not prepared to maintain both the original form of the PNG
(like the RTF renderer expects) and the decoded form as currently the
PDF renderer expects. Actually, PDF would be able to process the
undecoded form of the PDF, too, but that's not implemented, either. I
guess I finally have to write that detailed specification of the
improved image library I have in my head.

On 01.02.2007 23:29:03 Andreas L Delmelle wrote:
> On Feb 1, 2007, at 21:53, Koen Heene wrote:
> 
> > <snip />
> > I have the feeling that the image cache doesn't properly reuse the
> > image (maybe because of the multi threaded environment), holds a lock
> > on the PNG file and therefore doesn't allow that file to be re-read.
> 
> Looking into the code, it seems like clearCaches() should be removed  
> (it is used nowhere; if it is not meant to be called, then it should  
> be suppressed).
> 
> In the normal course of events, images are released via a call to  
> ImageCache.releaseImage(). clearCaches() works differently, leading  
> to this strange NPE...
> 
> What Exception do you get when a PDF is rendered first? There's a  
> patch in queue (bugzilla 41488) which may solve your problem.
> 
> 
> HTH!
> 
> Cheers,
> 
> Andreas



Jeremias Maerki

Reply via email to