[daisy] image update is not reflected in the pdf

[Jorg Heymans]

Done, DSY-626.

Thanks
Jorg

On Thu, Mar 13, 2008 at 9:14 AM, Bruno Dumon <bruno at outerthought.org> wrote:

>
> 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/
> _______________________________________________
> daisy community mailing list
> Professional Daisy support:
> http://outerthought.org/en/services/daisy/support.html
> mail to: daisy at lists.cocoondev.org
> list information: http://lists.cocoondev.org/mailman/listinfo/daisy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cocoondev.org/pipermail/daisy/attachments/20080313/d3ec2233/attachment.htm