On Wed, 2002-11-06 at 09:55, Jeremias Maerki wrote:
> While investigating the multi-threading issues in the maint-branch I
> came across the following:
> Currently, in the context of the PDF renderer, every FopImage is closed
> as soon as it's written to the target file. The next time the same
> image/url is used it has to be reloaded. This is not true for the other
> renderers, where the images are really being cached. The calls to
> FopImage.close() in PDFXObject are effectively disabling the caching
> mechanism. But on the other side it enables the correct working of urls
> that deliver dynamic content (only for PDFs), when the same URL can
> deliver different content over multiple invocations.

I don't think that can happen, the reason that the PDF renderer can
close the image is that the image data is stored in the PDF document,
further uses of the image should only insert the reference to the image.

> Which brings me to my idea. I don't know if we had that before. Wouldn't
> it solve this problem if we defined a proprietary extension for
> fo:external-graphic to specify if a given url is not to be cached? The
> content-type attribute can obviously not be used for that purpose. How
> about this?
> <fo:external-graphic src="url(http://localhost/mydynamicimage)" 
>xmlns:fop="http://xml.apache.org/fop"; fop:disable-caching="true"/>
> Default for disable-caching would be "false".
> This could also be useful for the redesign, where we have the same
> problem: When can and should we cache an image?

As Oleg pointed out it doesn't really make much sense to change the
image in a single document and would make things different.

Changing between different documents is a different issue.
The image caching could never cache an image but this is not really
something that could be specified inside a particular fo document. So I
think it would be better handled in some other way.

> Currently, I'm thinking if I should just delete the FopImage.close()
> method, so the behaviour of image handling is the same for all renderers,
> but that results in a semantic change for the PDF renderer. To still be
> able to serve dynamic images the above would be necessary.
> Any thoughts?
> Jeremias Maerki

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to