Probably the URI is validated during the XML/XSL to FO transformation,
and the validation requires a call -- you can check that by returning an
invalid response. In any case, the official input for FOP is FO and the
caching was implemented with that in mind.
You can tweak your URIResolver to not call the DB and just return an
"OK" response the first time it is called for a particular URI.
You can tweak your URI resolver
On 12/5/14, 2:55 PM, Marc Bleron wrote:
Hi,
Using FOP 1.1 on Java 1.5
I have SVG images stored in a database (Oracle 11.2) which I want to include
in a PDF document.
To achieve that I've created a custom URIResolver listening to a specific
uri scheme, and used that uri as source for fo:external-graphics, e.g.
<xsl:template match="Object">
<fo:block>
<fo:external-graphic src="url('cache:/media/{@cache-id}')"
content-width="scale-to-fit" width="100%"/>
</fo:block>
</xsl:template>
While transforming and rendering the output document, the URIResolver then
issues the corresponding query against the db using the cache-id value and
returns a StreamSource. That works fine.
The "problem" is that the URIResolver (and therefore the db) is called twice
when building the PDF document : once when transforming my input XML into FO
and another time when rendering the PDF from the FO.
My question is : is that intended behaviour? Isn't the caching mechanism
supposed to work in this situation?
Just want to be sure.
When using a FO object directly (identity transformation), the URIResolver
is called only once.
Thanks for any pointers.
Marc.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
