btw, what about raising the issue on xsl-editors? Definitely a lot of things are implied, but actually xsl spec says just nothing.I think it would be prudent to follow the same for fo:external-graphics and fo:color-profile, on the ground that FOs may be rendered out of order and, even more important, it is not clear whether multiple renderings of an external graphic in a static content, table header/footer or a marker should result in multiple access to the source. Unfortunately, the spec doesn't even mention this issue.
Good idea, worth to be added to the feature request list in order not to be forgotten.- Caching images across renderings definitely is an issue too (think of the company logo in each page header in every document), but FOP shouldn't solve this. I imagine a SourceResolver interface which gets an URL and optional content type and returns a XMLReader/InputSource pair. In case of binary image formats the default implementation returns a null parser. People who want to cache images across renderings can implement their own resolver which can do the caching. The Cocoon crowd will certainly rejoice (no more memory leaks due to FOP caching, access to Cocoon caching and Cocoon internal pipelines and other advantages).
I don't get it a little bit, why error should be generated? What's wrong with reloading an image each time it's referenced?- 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.
- Dynamic URLs. In order to achive this, we can extend the functionsThis one looks dubious for me. Can we add any new functions to the core library? Extension functions in different namespace like we used to in xpath are certanly not allowed in xsl as FunctionName here is NCName in contrast to QName in xpath. One more fault in the spec I think. :(
in property expressions by concat() and page-number().
Multiconn Technologies, Israel
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]