xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-François El Fouly <jean-franc...@elfouly.fr>
Subject Re: Major issue with image loading in FOP 0.95beta
Date Tue, 06 May 2008 08:29:52 GMT
Jeremias Maerki a écrit :
> I've just re-read that and it suddenly made me think: could it be that
> you produce really large FO documents (not many smaller ones) with many
> images and the effect here is simply the timeout of the HTTP connection because
> it is kept open after preloading the image? I'll add a system property
> to the image loader framework so you can disable the stream reusage.
> That could work around the problem. For a longer-term solution I see two
> possibilities:
> 1. Add a hint to fo:external-graphic that a URL is dynamic and that the
> stream should be reused. Otherwise, it is closed immediately and
> reopened when the full image is read. That idea is not new but never got
> realized.
> 2. Add some intelligence to the stream cache so it closes the stream if
> it is not rerequested within a given time frame to avoid timeouts.
>   
In fact we produce a very large document but it used to make FOP explode 
(OutOfMemoryError) just to generate one section. So we generate each 
chapter separately and "bind" them using iText. Basically that is why we 
need 0.95beta to use the named destinations, otherwise we can't add 
bookmarks at the end.
So the problem occurs generating just one chapter.

Here are the figures:
- That chapter has 174 images, 84 unique PNG's for a total of 14 Mb. The 
smallest image is 2 kb, the largest is 395 kb.
The whole chapter generated with FOP 0.94 is 69 pages, for a PDF that 
weighs 14.8 Mb.

The whole document is about 900 pages and currently weighs about 150 Mb.

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Mime
View raw message