Relative path to the image/picture in document

English
, , , ,
#1

Is there any possibility to use relative path for inserted pictures/images in Libreoffice 6.3.4.2 documents?

In tool → options → load/save → general → save I have got checkbox "Save URLs relative to file system" checked but it seems not work for images/pictures.

When I try to add picture with link option I’ve got message:

The file C:\folder\final_install.png will not be stored along with your document, but only referenced as a link. This is dangerous if you move and/or rename the files. Do you want to embed the graphic instead?

When I choose Keep Link and look in Properties of inserted image I see absolute path to picture instead of relative:

file:///C:/folder/final_install.png

#2

I see absolute path to picture

The important word is see. The UI always presents the current location with respect to the documents location and shows you the full path and the only way for you to recognize the relative nature of the link, is to move the document to different locations (directories) on your system and see again.

#3

Hello,

from my pov Tools -> Options -> Load/Save -> General -> Option: [X] Save URLs relative to file system does work, but you always see the updated full path to the image(s) and sadly there is no Show relative URLs in relative format option. Just create a new document, add an image linked (and option [X] Save URLs relative to file system set), close the document, move the document to a new location and open the document. Now see, where the document expects the image to be.


It’s a bit weird, that you got no easy way to recognize from the image location, that it is a relative location but from content.xml (part of the ODF zip container) you could see:

<draw:image xlink:href="../../Images/Screenshot_20190620_172833.png"

that the path is stored relativ to the document’s location.

Tested using LibreOffice:

Version: 6.4.1.2, Build ID: 4d224e95b98b138af42a64d84056446d09082932
CPU threads: 8; OS: Linux 4.12; UI render: default; VCL: kf5; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US, Calc: threaded

Hope that helps.

If the answer helped to solve your problem, please click the check mark (:heavy_check_mark:) next to the answer.

#4

Ok, now I know where is the problem. I need path relative to document not relative to actual path of document.

So if I have ODF document in C:/ with relative path to image from ./folder/final_install.png and I decided to copy this document do ./folder the path will change from C:/folder/final_install.png to C:/folder/folder/final_install.png. I expected always “./folder/final_install.png” no matter when ODF document is.

#5

No - you seem to not have understand my answer. You got no problem. The problem is that you don’t see the relative path. Just use the option and you get what you intend.

#6

changed .docx file format to .odt and it’s working. Thank you! :slight_smile:

#7

You did not mention, that you used .docx

#8

from my pov Tools → Options → Load/Save → General → Option: [X] Save URLs relative to file system has been checked. I saved the file as ppt (since the target user doesn’t user LibreOffice). After defining the links, instead of moving the hyperlinked document to a different location in the same laptop, I changed the name of the parent folder. In the slideshow the hyperlink doesn’t work. My intention was to send the ppt over email. The error message is provided below.

"file:///C:/Users/jesuwa/Documents/NFPP1/SGOS_NFPP_11Aug2020/RMS%20(2020-2021)%20Wheat%20Reports/RMS%20(2020-2021)%20reports/FarmersRegistered%20RMS%20(2020-2021).pdf" is not an absolute URL that can be passed to an external application to open it.

ajk

#9

@AJKJose

I saved the file as ppt

Don’t expect an LibreOffice option to work in alien formats and see my comment to OP.

#10

I just saved a document, using .odt format, with Tools -> Options -> Load/Save -> General -> "Save URLs relative to file system" checked, with version 6.3.4.2.0+ of LibreOffice, and the resulting file had this path in its content.xml:

<draw:image xlink:href="../../../../../../../../home/chad/mydocs/projects/ProjectName/Documentation/Assets/IMG_20181227_182136%20-%20before%20-%201280x960.jpg" [...snipped...]>

This is, uh, technically a relative path. Sorry though, it’s not useful to me. It assumes that large portions of the filesystem surrounding the document will still have the same structure as they original did. They won’t.

For completeness, I tried saving with that option unchecked. I found this path within content.xml:

<draw:image xlink:href="file:///home/chad/mydocs/projects/ProjectName/Documentation/Assets/IMG_20181227_182136%20-%20before%20-%201280x960.jpg" [...snipped...]>

That’s an absolute path, which is what I expected, but not what

#11

…

I was expecting LibreOffice to normalize its relative paths.

What I’m looking for is this:

<draw:image xlink:href="Assets/IMG_20181227_182136%20-%20before%20-%201280x960.jpg" [...]>

Or because I later realized that the “current directory” for the href is something like /doc/path/document.odt/ and not the folder /doc/path/ as I expected, then it perhaps it should be this:

<draw:image xlink:href="../Assets/IMG_20181227_182136%20-%20before%20-%201280x960.jpg" [...]>

Having the relative paths be normalized is important for almost any scenario where I send someone a folder containing my document alongside assets used in the document. It is very unlikely that another person would place the document in a folder that just happens to have exactly the same path (or path ending) as the document’s absolute path on my machine.

I have almost 100 images in this document, and they are photos (large, high-res things); embedding is not practical.

…

#12

…

A note for anyone who is unfamiliar with what’s going on: a .odt file can be copied+renamed to a .zip file and then unzipped. You may want to dump the .zip file in its own directory first. Just sayin’ :wink:

The result is a bunch of files like this:

$ ls
Configurations2  content.xml  Fonts  layout-cache  manifest.rdf  META-INF  meta.xml  mimetype  settings.xml  styles.xml  Thumbnails`

The content.xml file I mentioned earlier is at the top-level of this bunch (and thus directly visible in the listing above). You can edit this file with a text editor. Just be careful that you don’t use an editor that will modify the file in unintentional ways, like how Notepad (but not Notepad++) would change the line endings from \n to \r\n (or at least did at one point), or any program that would truncate very long lines. Because this file has very long lines.

…

#13

…

So like with XKCD 208 (xkcd: Regular Expressions), I am thankful that I KNOW REGULAR EXPRESSIONS!

Though, if your paths are both uniform and distinct enough, you might be able to get away with a plaintext search-and-replace. In my case, this was actually true.

And so I compelled my computer to replace all of those paths with ../$THE_CORRECT_ANSWER, then I saved content.xml and packed the .odt back up.

It seems I will now have to do this every time I save the document, because saving DOES alter these paths. And that’s with “Save URLs relative to file system” NOT checked. (Beware of autosave!)

…

#14

…

I see room for improvement:

  • Instead of having a checkbox named “Save URLs relative to file system”, have a radio button like so: For resource paths: On save { (*) Convert absolute paths to relative ones | ( ) Convert relative paths to absolute ones | ( ) Do not convert paths }

  • I hinted at it, but to be clear: “Convert absolute paths to relative ones” should be the default.

  • If this is only used for images, it’d be even better to write “For resource paths:” as “For image paths:”.

  • If “Convert absolute paths to relative ones” is selected, it should not just emit relative paths, it should emit normalized relative paths. That is, anything like ../../a/b/c must be converted to c.

  • If the “relative to file system” possibility is an important feature for someone, then add a checkbox named “For resource paths: On save, normalize relative paths” that is checked by default. Then, if these users want to get ../../a/b/c instead of c, they can uncheck this box.

#15

…

Here’s why I would choose normalized relative paths as the default:

While I could see absolute paths being circumstantially useful in corporate or team settings where a document’s assets are centrally edited or controlled, this is not the most common use-case, and even those users should consider placing the centrally-controlled assets onto an (e.g. private) HTTP server and then having the document links use remote URLs (ex: https://our-server/path/to/file.jpg) to reference the assets. Absolute file paths are incredibly fragile.


Well, that's all I have.

Be well, everyone.

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.