Oleg Tkachenko wrote:
Jeremias Maerki wrote:

Thanks for answering. Do you have a pointer to some documentation
describing that side-effect free policy?
Unfortunately not. xsl requirements and xsl proposal states intensions for xsl to be side-effect free language, like its dad dsssl, but as side-effect free xslt is now a separate recommendation, xsl-fo is staying in its shadow.
Well, XSLT explicitely specified that document() must always return
the same tree during a transformation run. It does not explicitely
say whether the source is only accessed once or multiple times, and,
quite predictable, Xalan accesses the referenced URL every time it
encounters a document() call (even though it seems to discard the
read tree in favor of the cached tree), while Saxon and libxslt
access the URL exactly once.
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.
Mind you, there was already a complaint where someone used a
fo:external-graphic in a page footer for images representing page
numbers and of course didn't get what he expected.
In XSLT, for document(), it can be argued that it should be easy to
arrange for an additional dummy parameter in order to have distinct
URLs, for example
  <xsl:value-of select="document('http://ts.com/get-time.cgi?start')"/>
  <xsl:call-template name="template-to-profile"/>
  <xsl:value-of select="document('http://ts.com/get-time.cgi?end')"/>
Of course, nothing prevents the XSLT processor from fetching both
values first and then going on with evaluating the template in between,
therefore this technique is risky at least.
A similar approach oviously wont work for fetching graphics repressenting
page numbers.

Conclusions and ideas so far:
- FOP should cache external graphics during a rendering and by default
  clear the cache afterwards.
- 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
  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).
- 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 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.


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to