[daisy] image update is not reflected in the pdf

[Bruno Dumon]

On Wed, 2008-03-12 at 13:41 +0100, Jorg Heymans wrote:
> 
> On Wed, Mar 12, 2008 at 12:12 PM, Bruno Dumon <bruno at outerthought.org>
> wrote:
>         It's FOP who caches the images. When we used the FOP 0.20
>         series, we had
>         a component which cleared FOP's cache from time to time (since
>         otherwise
>         it never got evicted and hence could cause memory leaks). I
>         don't know
>         how the caching in FOP 0.9 works, and if it's possible to
>         invalidate it.
> 
> From http://xmlgraphics.apache.org/fop/0.94/graphics.html :
> ===============
> FOP caches images between runs. There is one cache per FopFactory
> instance. The URI is used as a key to identify images which means that
> when a particular URI appears again, the image is taken from the
> cache. If you have a servlet that generates a different image each
> time it is called with the same URL you need to use a constantly
> changing dummy parameter on the URL to avoid caching. 
> 
> The image cache has been improved considerably in the redesigned code.
> Therefore, a resetCache() method like in earlier versions of FOP has
> become unnecessary. If you still experience OutOfMemoryErrors, please
> notify us. 
> 
> 
> ===============
> 
> so when i change resources/skins/default/xslt/document-to-xslfo.xsl
> 
>   <xsl:template name="insertGraphic">
>     <fo:external-graphic src="url('{@src}">
>     ....
> 
> to 
> 
>    <fo:external-graphic src="url('{@src}?test123">
> 
> 
> then i'm getting the new image in my PDF, neat! 
> 
> 
> random() or now() don't seem to be supported in standard xslt though,
> so perhaps there is some random-enough data available elsewhere in the
> document that we can append to the URL each time? Should this be made
> the default behaviour also you think ? Other than performance (impact
> to be determined) I don't see any reason for FOP to maintain a
> separate image cache.
> 

The random number is fine as a solution, but to exploit the caching we
could use the image's version number instead.

This would be:
 * if the version number is specified in the image link, than that
 * or else the version number of live/last version of the image,
depending on whether the wiki is in staging mode or not

This version number could be added as part of the "p:linkInfo" (the link
annotation information which is added to each link by the publisher).

So, not something which is immediately possible, but shouldn't be too
hard to add. Maybe you can make a jira issue for this?
(http://issues.cocoondev.org)

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought                            http://www.daisycms.org/
bruno at outerthought.org              http://www.kauriproject.org/