Re: [RT] Proprietary extension to fo:external-graphic

[Oleg Tkachenko]

J.Pietschmann wrote:

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.

btw, what about raising the issue on xsl-editors? Definitely a lot of things are implied, but actually xsl spec says just nothing.

- 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).

Good idea, worth to be added to the feature request list in order not to be forgotten.

- 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.

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?

- Dynamic URLs. In order to achive this, we can extend the functions
available
in property expressions by concat() and page-number().

This 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. :(

--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel


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