Re: [xsl] xsl can't get graphic to load from xml file

Subject: Re: [xsl] xsl can't get graphic to load from xml file
From: Eliot Kimber <ekimber@xxxxxxxxxxxxxxxxxxx>
Date: Thu, 07 Apr 2005 13:59:48 -0500
There is no simple single solution to this problem because it depends entirely on the relative locations of the FO instance (if you are generating an instance) and the graphic *at the time you render them*, not at the time you generate the FO.

Therefore, for different processing environments, it might be most appropriate to generate an absolute path and in others you have to generate a relative path relative to some pre-defined location.

In addition, doing path processing is generally easier in a language like Java than in XSLT (although you can do it in XSLT, of course). For example, we have utility Java libraries that do things like compare two paths and return the shortest relative path. We then expose these through Saxon extension functions so that in the XSLT we can easily generate relative paths to graphics given some base path (normally passed in as a parameter to the XSLT process).

For one customer we have to provide an FO-generation-time option of whether graphic paths are relative or absolute because different users of the code have different business rules.

Finally, remember that relative paths will be relative to the location of the FO instance, not the original XML document (unless you set the xml:base attribute in the FO instance to be the location of the orignal XML document), which can be a problem, especially if you generate the FO instance and then move it somewhere else before rendering it.

This is all presuming that your graphics are not managed in some URL-accessible content store that would allow you to specify location-independent absolute URIs. In essence, all the W3C specifications assume that this is the case, even though for most users it is never the case.

Cheers,

Eliot
--
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8155

ekimber@xxxxxxxxxxxxxxxxxxx
www.innodata-isogen.com

Current Thread