relative image paths instead of absolute

Since "[ 979858 ] image xlink: pixmaps linked with relative
path don't work" is closed/fixed now, I think this RFE can
be closed too

Think this is fixed now

They are relative in CVS as far as I can see.

It looks like we have this bug again, four years later.
I'm using Inkscape pre3 from testers ppa (ubuntu jaunty, 64 bit)
Every image I import is linked absolutely, with a file://path link.
No matter what I do, the images are always absolute.

That makes pretty tedious to work with other people on the same files over a network. You have to manually edit all the image links and make them relative (and that's ugly when you have dozens of images in your file).
It worked almost fine in 0.46 (except for the bug #272520) but it was far better than this, so I reopening this bug and marking it with high importance since it's clearly a regression.

(You didn't notice it until now? not a regression then… ;-)
Yes, all images are linked with absolute pathnames in URIs now.

related reports that have recently dealt with issues of
 a) filename vs. URI
 b) relative vs absolute path
(besides RFEs for improved linked bitmap options):

bug #168484 lets Inkscape use URIs instead of local file names (comment #6)
bug #386069 fixed embedding of absolute path names URIs for linked images and
bug #386664 needs to replace absolute with relative URIs when exporting to ZIP.

~suv: I noticed it some time ago but waited until it drove me completely nuts doing a brochure with dozens of images to report it. :-)
Thank you for the related report links.

A patch is currently in progress.
It works correctly when an image is imported in a saved document (the SVG has a path) but not with a newly created document which is saved after the image is imported.

First patch attached.

Tested on Windows XP and Ubuntu 10.10, revision 10074.
On Windows, relative hrefs are saved as pathnames with / as path separator (instead of \) so that they can be opened on other operating systems. Thus they can be considered as relative IRIs and thus conform to the W3C recommendations (I'll dig a bit later to be absolutely sure of it).

Known bug: an image imported in an unsaved new document needs to be saved twice before being saved as relative.

There's some work left, but you can already test and comment!

testing patch with r10078 on OS X 10.5.8 (i386), command-line version (not osx-app):

When importing an image from a sub-directory relative to the location of the saved SVG file, these console warnings occur, from 'src/sp-image.cpp' (IIRC not new):

** (inkscape:67215): WARNING **: <image xlink:href="168244-test-renderer-gdkpixbuf/drawing-1.png"> did not resolve to a valid image file (base dir is /Volumes/blue/img/Inkscape/test/bug/168244-test-renderer-gdkpixbuf), now trying sodipodi:absref="/Volumes/blue/img/Inkscape/test/bug/168244-test-renderer-gdkpixbuf/drawing-1.png"

Just curious - when are linked images 'rebased' (if possible) - on save or on load?

Error message confirmed. It's due to a problem with base path of images that are not in the same directory as the SVG file.

> Just curious - when are linked images 'rebased' (if possible) - on save or on load?

On import AND on save (when necessary). Images with absolute path (URI) are rebased only when the SVG file is saved in a different directory.

Related: Bug #272520 "Dragging and dropping images into the inkscape document always creates an absolute link"

When saving the attached SVG file with a different filename, Inkscape r10107+patch crashes consistently - the trigger seems to be this image:

    <image
       x="321.30518"
       y="708.66998"
       width="152.54485"
       height="143.18517"
       href="Vk Werner Reisender_Images\Vk Werner Reisender_ImgID1.png"
       id="image5144"
       style="fill:#a619ff;fill-opacity:1" />

As far as I know, the image was originally created with Inkscape 0.47 (possibly pre4?) on debian sqeeze, though the relative href path must have been written with an older Windows version?

back trace

I must admit I haven't tested with old (0.46 and older) files. I'll try this one tomorrow on my patched Inkscape version.
Thanks again for your tests!

@~suv - The image in your document uses href directly, and not xlink;href as expected. Thus the issues is not due to an incorrect pathname handling (it works if you use xlink;href with the same path) but triggered by a missing NULL pointer test (needed when there's no xlink:href attribute at all). Now it's fixed locally (I'll send a new patch later, hopefully with other fixes).

I confirm that the warning message "did not resolve to a valid image file..." existed in 0.46. This behavior is known and commented in the src/sp-image.cpp, line 1243:
    "document base can be wrong (on the temporary doc when importing bitmap from a different dir) or unset (when doc is not saved yet)..."

I could try to fix it by comparing the filename (without path) and the (false) image base with the abref attribute to confirm the xlink:href is ok, but it would eat some CPU cycles that are IMHO not really necessary. The absref fall-back works correctly with this special case as it does with broken xlink:href.

BTW, I can't reproduce the bug I mentioned in comment #8.

New patch version, with NULL pointer test.
If there's no new issue with this one, I think I'll commit it soon.

I've poked at this a few times in the past... but I'm thinking that we want to do this in C++, not C. A minor shift in approach could be helpful.

> I'm thinking that we want to do this in C++, not C.

I reused the same syntax as the original code. And since it was not part of the recent C++ification, it still needs refactoring.

> A minor shift in approach could be helpful.

Could you please give some details? Do you mean the patch could be made differently (and more efficiently) or the whole code?

Would you mind if I commit the current patch? As far as I can tell, it doesn't add any regression compared to how relative links worked with 0.46 and doesn't break anything else in Inkscape. If it's a matter of C++ification, I guess that's something we could do after the bug is fixed. Except of course if there are horrors in the patch...

Fix committed in the trunk, revision 10124.

Absolute addresses can be useful too. Specially, when one is making a web site and, let's say, the logo has to be included in many pictures, then one doesn't need several copies of the logo. If the logo changes a bit, it's fine if all the SVG pictures including it change at once, and if the SVG pictures can be moved without the links being rewritten.
I think the import dialog could give 3 alternatives, not 2 as in Inkscape 0.48.0: "embedded"/"linked to absolute address"/"linked to relative link" and explain the 3, for instance: "Use absolute address for pictures you won't copy and whose address is stable and can be shared, specially pictures on the web, including pictures in your website.".

This is a security issue because all drawers are not computer specialists and, sending or distributing their work they can disclose unawares the absolute path of their picture, so information of their directories and files hierarchy, usually including their username in the system.
Since it is a security issue, its patch should be distributed to Linux distributions without waiting for Inkscape 0.49 .

@Fiable.biz - IMHO it would be imprudent to backport the patch at this stage to any stable version:
a) this is work in progress, and the code likely to change (C++-ification)
b) this is work in progress with regard to image handling and management (see blueprints related to this report)
c) the patch doesn't address your security concern:, it's about finding and loading images on Inkscape (there is still an absolute path reference associated with the image (attribute 'sodipodi:absref'), even if the path to the image can be relative)

@JazzyNicco, any comments?

> @JazzyNicco, any comments?

a, b) the patch is very recent, and it would indeed be safer to use it extensively in the trunk before backporting it. That's something we can discuss later with the 0.48.2 release plan.
As for c), saving as Plain SVG removes the sodipodi:absref and thus addresses your security concern.

I recently encountered this issue after a Win XP reinstall -- my SVG files were previously stored on drive letter H, now on drive letter F, breaking the absolute URIs. At least fixing it was a straightforward find/replace operation on the SVG tree (though just a little tedious, having to do it across several files).

One idea is that the modal popup that asks whether to embed/link an imported image can also ask whether a linked image should be absolute or relative.

Here is a workaround that has been working for me for a while (maybe 3y or more). After adding an image, right click on it, select "Image Properties". Manually edit "URL" to be a relative path. Save and the resulting svg will have the relative path (and it should not get changed back to absolute).

Or, use a text editor and make the same change directly to the xlink:href elements in the affected image(s).

Both of these are annoying and afaik undocumented, so it will still be nice to see this finally get fixed.

In Inkscape 0.48.4 r9939 on win32, relative links such as xlink:href="splash-release.svg" is not resolved. At save, inkscape creates an attribute sodipodi:absref="C:\git-repositories\jabref\jabref\src\main\resources\images\splash-release.svg", which points to the correct file, but during load, the image is still displayed as "Linked image not found".

Tested and found to be partially working on Win 8. (Yesss!!)
Furthermore, there's no difference between using \ or / as a folder delimiter in the paths on Win 8.

1. Created new Inkscape file and put it into "foldername-1".
2. Added some random GIF, JPG and PNG-files to a subfolder called "subfolder"
3. Drag-and-dropped files into Inkscape file.
4. Closed Inkscape, renamed parent folder to "foldername-2".
5. Opened Inkscape.

Result:
Linked image files were still loaded as the xlink:href is still relative.
Really good! :D :D :D

However, if some of the paths are absolute, Inkscape 0.91pre4 r13712 crashes upon loading the file.
Furthermore, for some reason, it's possible to import a JPG or GIF file into the same SVG. Any combination of JPG+PNG or GIF+PNG works but GIF+JPG crashes Inkscape upon importing the second file.

I've just confirmed that both new bugs exist in the release version of Inkscape 0.91 r13725 for Win64 on Win8.
*JPG+GIF linking crashes Inkscape as described above.
* Loading a SVG file which contains both absolute and relatively linked files crashes Inkscape.

Cheers.

@Jarl, I can confirm that Inkscape crashes when linking a JPG and a GIF file with 0.91 for Windows 8 -64-bit). The good news is that I can't reproduce the bug with 0.92 on the same computer.

As of the file with both relative and absolute links, I can't reproduce the crash at all, even with 0.91. Could you please try with 0.92 and confirm it's fixed? If not please open a new specific report.
Thanks for your comments!

JFTR - the crash triggered by certain combinations of different types of bitmap images in 64bit Inkscape 0.91 on Windows (e.g. GIF+JPG) is tracked in bug #1467103.