dtbook-to-odt creates absolute links to path on server when images=linked

[egli]

When the images=LINKED option is enabled the odt contains links to the images instead of the embed image. That is fine. The problem however is that the xlink:href points to a temporary path on the server

<draw:image xlink:href="file:/var/opt/daisy-pipeline2/jobs/8adbfdf8-dc55-4b9b-928f-b91a38ceee1a/context/der_staat/cover.jpg" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/>

If I modify these links to a relative path and place the images in the same directory as the odt file, the file opens correctly and the images are showing.

<draw:image xlink:href="../cover.jpg" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/>

[bertfrees]

In other words, (the current behavior of) LINKED only makes sense in "localfs" mode. Should

• a new option be added that copies the images?
• LINKED be disabled when not in localfs mode?
• the behavior of LINKED be changed to always copy all the images?
• the behavior of LINKED depend on whether "localfs" mode is enabled or not?

[bertfrees]

I'm not even sure anymore what "copy" would mean 😕. Absolute paths just don't make a lot of sense.

I just checked that relative links also work in LibreOffice. But I can not get it to work in MS Word. The solution I found for LibreOffice also seems a bit of a hack: I had to use the following link:

xlink:href="file:../greatpainters-last_judgement.jpg"

[egli]

The solution I found for LibreOffice also seems a bit of a hack: I had to use the following link:

xlink:href="file:../greatpainters-last_judgement.jpg"

Why is that a hack? It's an improvement over the absolute path (on the server).

[bertfrees]

It's a hack because LibreOffice happens to resolve the relative link against the .odt file, treating this file as a directory (hence the ..). But this is of course not mentioned in the specification. And it does not work in MS Word.