On Wed, 06 Nov 2002 23:06:53 +0100 J.Pietschmann wrote: <snip/> > Conclusions and ideas so far: > - FOP should cache external graphics during a rendering and by default > clear the cache afterwards.
ok. > - 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). 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? > - 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. > - Dynamic URLs. In order to achive this, we can extend the functions available > in property expressions by concat() and page-number(). I believe both would > be welcome by many users for other purposes too (whether that't a good idea > is another matter). One of the possible concerns are usually name clashes > with future XSLFO extensions. Using prefixed identifiers like fox:concat() > would be a solution, I'm somewhat uneasy with using XML namespace mechanisms > within values for XML attributes. In fact, I think its abuse, but I can't > offer much better ideas either. I think you've got me wrong what I meant with dynamic URLs. I called the URL dynamic if the same URL can deliver a different content with each call. For example something similar to your example: http://ts.com/get-time.cgi Each time the URL gets called it returns a different image showing a clock giving the current time. It's a problematic discussion, somewhat. We're talking about image caching but there are at least two separate kinds: - Caching of images inside one processing run (which I consider the renderer's duty to a certain degree. Of course, the layout engine has to determine the extents of the image before the renderer goes into action) - Caching of images over a longer time and between processing runs. I agree that a specialized SourceResolver is a good thing but I still wonder about the decoding work. I was primarily wondering about the second kind of caching, but the discussion went stringly towards the first kind. Anyway, I'm still somewhat unsure about all this. 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. Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
