xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 46048] Wrong images used (how to clear image cache?)
Date Tue, 21 Oct 2008 13:01:56 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=46048





--- Comment #14 from Jeremias Maerki <jeremias@apache.org>  2008-10-21 06:01:55 PST
---
(In reply to comment #13)
> Thanks for all these ideas! We first create all data (XSL, XML, SVG) in a
> temporary directory for each report. Then we call FOP to transform the XSL+XML
> to PDF. The references to the external SVG files are in the XSLs (as relative
> paths to these files).
>
> With this approach, other developers first design the report "offline" on their
> workstation with their tools. We can also re-create the PDF anytime later with
> third party tools like fop.bat instead of our Java application. For debugging,
> we can look in any xsl, xml and svg as the files are there.

This sounds like we might have to rethink how we treat the URI when caching the
image. If it's a relative URI, we'd have to prepend the base URI and only use
the absolute URI in the image cache. I don't think we do that now. That could
actually solve your problem.

> Anyway, I wonder
> how you can generate the SVG on the fly and pass the SVGDOMSource to FOP, as
> the image cache is ignoring the URIResolver anyway (as I learned now).

The thing is: We assume that a resource can be identified uniquely by its URI.
After all there's the word "identifier" in "URI". If the same URI comes back,
we assume it's the same image. The URIResolver is only used when we have to
load the image (which is done once). The image loader framework then puts the
loaded image (subclass of org.apache.xmlgraphics.image.loader.Image) into the
cache under this URI, further identified by the ImageFlavor (as multiple
representations of the same image can be stored in the image cache). So if you
re-request the same URI again, the cache returns the image directly. No detour
through the URIResolver.

So, to pass in an SVG DOM, your URIResolver will create a DOMSource instead of
a StreamSource. PreloaderSVG can make use of a DOMSource, so it doesn't have to
be serialized to a stream first, in case you build your SVG as a DOM somewhere.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Mime
View raw message