Relative references in svg:image elements aren't resolved correctly

[slucchini]

I have a document with an reference and an svg:image reference and the svg:image is behaving weirdly. I have a folder structure as follows:

svg-testing
  +--documents
  |    +--concept.dita
  +--resources
  |    +--logo.png
  +--map.ditamap

And the files are written out below:

map.ditamap

<!DOCTYPE map PUBLIC "-//OASIS//DTD DITA Map//EN" "map.dtd">
<map>
    <title>SVG Testing Map</title>
    <topicref href="documents/concept.dita"/>
</map>

concept.dita

<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA 1.3 Concept//EN" "concept.dtd">
<concept id="concept_vq1_c3c_3s">
    <title>SVG Testing</title>
    <conbody>
        <p>
            <image href="../resources/logo.png" width="400"/>
        </p>
        <p>
            <svg-container>
                <svg:svg xmlns:svg="http://www.w3.org/2000/svg" width="400" height="300">
                    <svg:image xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="../resource/logo.png" width="400" height="300"/>
                </svg:svg>
            </svg-container>
        </p>
    </conbody>
</concept>

logo.png

Is any old image, I've been using this:

The image is published successfully, however I get an error from the svg:image:

[fop] The URI "file:/Users/slucchini/Downloads/DITA-OT1.8.4_DITA1.3_Default/temp/temp20150610151611018/../resource/logo.png" [fop] on element can't be opened because: [fop] The URI can't be opened: [fop] /Users/slucchini/Downloads/DITA-OT1.8.4_DITA1.3_Default/temp/temp20150610151611018/../resource/logo.png (No such file or directory)

It seems that it is trying to resolve the xlink:href (on the svg:image element) with respect to the path of the root map, not the path of the topic that contains it.

Any help would be greatly appreciated! Thanks!

• Scott Lucchini

[drmacro]

I could not reproduce the behavior as reported, namely that the image was published but the reference was wrong.

Rather, with map and topic with the SVG as shown and the SVG as authored pointing to the image in a location under the root map, the referenced image is not copied to the output, which is what I would expect as the OT has no knowledge of the image and does not do a blanket copying of images from the source directory to the output directory.

However, I did determine that if you add a key definition for the image that the OT will copy it to the output and the reference will be correct.

However, it's possible that if you used @chunk or @copy-to such that the resulting inline SVG was not in an HTML file in the same relative location as the original source topic, that the resulting reference from the SVG in the HTML file would in fact fail. That is, the current code does not fix up references within the SVG to account for different relative locations of the SVG in the result HTML.

Implementing copying of the images in the SVG to the output would be difficult as it would require adding preprocessing steps that examine all the topics to find references to images from SVG and then copy those and then also extend or modify the URI rewriting currently done in support of @chunk and @copy-to to also rewrite any references within SVG files. The first of these would not be too hard but the second could be quite problematic due to the nasty @chunk code in the 1.x OT.

This will require more research, but given that there's an easy workaround (key definitions) this can be a lower priority.

Full support for SVG in the 2.x OT should address this issue as part of its base implementation.

[drmacro]

For PDF, the reference in the SVG is relative to the location of the topic.fo file, which will be in the temp directory configured for the PDF process.

The current SVG-to-FO process is simply copying the SVG markup to the FO as-is, which means that relative URLs in the SVG aren't rewritten, which means that the referenced images need to be put in the correct relative location.

But that is probably not realistic.

Again, this requires some preprocessing the copy the embedded images to an appropriate location and then have the FO generation process know what the mapping is between images as referenced in the source SVG and the copied images.

Not entirely sure how to do that, but if your preprocessor can copy the images then it could generate a separate XML file with the mapping of SVG file/image-URL to new URL and the FO generation process can then use that mapping to output the correct URL in the generated FO.