Possible to force relative folder paths for portability?

Hi.

When you back up your image, do you back up *both* the raster and the inkscape file? Since Inkscape (should) work with relative paths, the raster image should still be available in Inkscape if you move both files and keep them in the exact same relation to each other.

Example:

C:\Folder\MyInkscapeFile.svg
C:\Folder\Images\MyLargeImage.tiff

if you move both files and keep their relative hierarchical position, it should be ok. Meaning: as long as the example inkscape file is in the same folder as the Images folder and the large image is inside that folder, Inkscape should definitly show the image when you open the file.

Even if you have moved both files to:

E:\My Backups\MyInkscapeFile.svg
E:\My Backups \Images\MyLargeImage.tiff

Cheers,
Jimmy Volatile

Actually, you're right. The paths are absolute until you manually make them relative, like you say. That's a major really a major flaw, in my opinion.

@Jimmy - AFAIK this behavior has changed since the last release. Current snapshots and the prerelease versions of 0.47 always store the absolute path when importing (not embedding) a bitmap.

@Michelle - ATM the only way to convert absolute paths to relative paths (of linked images) I know of is to export (Save as…) the SVG drawing as 'Compressed Inkscape SVG with media (*.zip)'. This output extension has recently been updated (<https://bugs.launchpad.net/inkscape/+bug/386664>) and works on Windows as well (for the first time). When you unpack the zip archive, you have a folder with the SVG drawing and all included bitmaps, referenced with relative paths.

For smaller projects with few images, you can edit the path by selecting the image > context menu > 'Image Properties' > URL and shorten the path of the image to a relative one. As long as you then move the drawing together with the linked images, the path in the attribute 'xlink:href' should stay relative.

I don't know if the attribute 'sodipodi:absref' will stay nor what it is used for. It contains the absolute path, but not encoded as 'file:///' URI (except after exporting as 'Compressed SVG with media').

@Jimmy
Thanks, but suv is right about the latest releases' saving method, hence my question.

@suv
I havn't used the zip method you mentioned above. I'll definately give it merrit for its worth, but sadly, it would not really solve my problem.

I am primarily a CD designer. This means svg files for every disc, the traycard front and back (2x svg), and every double page for the booklet. Each one of these images is in a particular folder relative to the project, with raster images in different relative folders as well, depending on whether or not it appears in more than one of the svg's.

For print-quality related issues I settled on using LZW-compressed tif's as my primary raster format. This means that compressing it into zip makes no useful difference. Using the zip method would actually require more space, as shared images would be put into multiple zip's, as opposed to one single relative folder.

I've been using the image properties dialog you mentioned above. This is just too time consuming. I'd recommend an option for relative paths at least in the save as dialog, but preferably also as a permanent choice in the Inkscape prefs.

Just a quick search in bugs.launchpad.net reveals many discussions about this issue - I'll just add the first few I found (my search deliberately included bugs with all statuses (?) and those that showed up all have the status 'Fix Released' ):

<https://bugs.launchpad.net/inkscape/+bug/246721> “docbase not updated when file moves”
<https://bugs.launchpad.net/inkscape/+bug/168542> “sodipodi:absref not updated by changing href in image props”
<https://bugs.launchpad.net/inkscape/+bug/225971> “Image embedding fails after imagefile name change”
<https://bugs.launchpad.net/inkscape/+bug/169094> “relative paths broken in all extensions”
<https://bugs.launchpad.net/inkscape/+bug/166024> “xlink:href lost on save”
<https://bugs.launchpad.net/inkscape/+bug/181993> “Image filter should resolve relative paths”
<https://bugs.launchpad.net/inkscape/+bug/165982> “Relative Locations <image> tags.”
<https://bugs.launchpad.net/inkscape/+bug/168484> “Relative links use "\" in win32 platform”
<https://bugs.launchpad.net/inkscape/+bug/165768> “image xlink: pixmaps linked with relative path don't work”
<…>

some bugs marked as Wishlist:
<https://bugs.launchpad.net/inkscape/+bug/168715> "Exports to relative paths should work properly"
<https://bugs.launchpad.net/inkscape/+bug/168752> "Optionally relative paths for imported images"
<…>

so I'm not sure what to propose here - besides adding more questions…
- It seems to be a known issue and settled with 'we adhere to the W3C SVG specification'?
- Maybe the changes to absolute URI xlink:href (in bug #168484 I think) have not yet been exposed with its all its consequences (I stumbled over this issue when two extensions had to be fixed in part to accommodate for this change)?
- Which of these (and other related) bug reports acts as a 'meta bug' i.e. which one to pick to bump it up again or to add a new proposal? (maybe I'd go for #168752…)

sorry for not having a better answer… ~suv

Rethinking my previous comment - maybe it would be better to initiate a discussion on the inkscape-user mailing list? To subscribe go to <https://lists.sourceforge.net/lists/listinfo/inkscape-user>, the archives are at <http://sourceforge.net/mailarchive/forum.php?forum_name=inkscape-user>.

<http://news.gmane.org/gmane.comp.graphics.inkscape.user> is a faster access to the archives - sourceforge.net is extremely slow recently.