Jeremias Maerki wrote:
- Caching images across renderings
But the SourceResolver approach will only let you cache the binary
representation of an image, quite often it still has to be decoded each
time it is used, which costs CPU power. Right?
Advertising
Right.
Next try: provide a layered set of interfaces:
- SourceResolver: resolves URI to XMLReader+InputSource. Used for, well,
source resolving for graphics, color profiles, fonts, font metrics,
perhaps config files, whatever.
Can be hooked into for URI mapping, custom protocols, on the fly
generation, simple caching.
Default implementation similar to the common
javax.xml.transform.URIResolver, with a few twists (must peek into the
stream to check for XML unless forced by content type).
- ImageResolver: resolves a URI+some properties (which?) into a FOPImage.
Default implementation uses SourceResolver to get a stream and whether
it is an XML stream, detects image type (unless forced by content type).
Can be hooked into for advanced image caching (still call the default
implementation for doing the image creation).
- FontResolver: Same for fonts.
- FontMetricsResolver: for completeness, or fold this into the FontResolver.
- ColorProfileResolver, : Just to be complete, or use SourceResolver
directly.
- Fine tuning: A single large image will block a lot of memory during
rendering. A possibility is a fox:cache="no" control property. In order
to preserve semantics, a null image is cached for this URL, and an error
is generated in case it is attempted to render the image a second time.
So, I may not be so far off the mark after all.
Revised thoughts: Two control attributes
- tentatively: fox:cache
+ yes (default): keep the FOPImageObject (for this rendering run)
+ no: discard it immediately after rendering.
Use this to prevent large images which occure only once to take up
memory indefinitely.
Problem: how should this be handled in static content, markers,
table headers/footers with omit-header-at-break="false"? Perhaps
"discard with FO" rather than "discard after rendering"?
- tentatively: fox:access
+ once (default): do not access the source if it has already been
accessed, if there is no cached FOPImage, raise an error
+ use-cached: do not access the source if there is a cached
FOPImage, else reload
+ on-creation: access source while creating this FO unconditionally,
replace cached image if there is one.
+ on-rendering: access source each time this FO is rendered.
Don't ask me how this should work together with the resolver stuff above.
Perhaps the fox:access stuff is overengineering, don't take it too serious.
- Dynamic URLs.
I think you've got me wrong what I meant with dynamic URLs.
I got it quite right. I should have mentioned I wanted to supply
a mechanism which allows the construction of different URIs in case
someone wants to use images for page numbers.
Maybe we have to set up a new page in Betrand's Wiki to create a little
specification for the image caching. This would also help as a
discussion base if we have to contact the XSL:FO WG as Oleg suggests.
Neat idea.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
