sodipodi:absref not updated by changing href in image props

[Josef Vybíral (cornelius)]

The sodipodi:absref value of the <image> element is not updated after
changing the URL of image in Image Properties dialog window opened using
the right mouse button on image. This causes a failure of embedimages.py
script because it depends on the value of sodipodi:absref and when it is
incorrect then wrong image is embedded.

Confirmed in 0.45, 0.45.1 and svn-head (r14700)

[Buliabyak-users (buliabyak-users)]

Originator: NO

embedimages.py now uses exactly the same sequence of searching for images
as inkscape itself, with absref as last resort. It used absref first,
previously, but it was a bug fixed in 0.45.1.

[Bryce Harrington (bryce)]

Please test against inkscape 0.46pre1 or newer, and see if the issue still exists.

[reader4 (cbrace1)]

I can confirm that the issue still exists in 0.46 built 4/7/2008. When changing the href, the sodipodi:absref value remains unchanged unless I enter the XML code to do it manually. As a result, embedding is very problematic unless absref values have not changed from the original import.

[reader4 (cbrace1)]

I should also point out that my problem was related to a relative link in the href: href="image1.png" while the entire path would be "/home/user/poster1/image1.png" where the SVG is located in "/home/user/poster1/". After looking at the embedimage.py script, I see a couple of problems:

1. 'absref' should be updated correctly by Inkscape. Hence this bug.
2. The embedding script should be able to use relative paths for 'href' using 'docbase' + 'href' long before it needs 'sodipodi:absref'; however, it appears that 'sodipodi:docbase' is not updated when the file moves. This should be updated when the file is opened to reflect the actual location ('docbase') of the SVG. Therefore, even though the embedding script looks at the image paths correctly, it is again failed by Inkscape's attributes. So, 'docbase' should also be updated correctly by Inkscape (see 246721).

[Malte Cornils (malte)]

This is a bit misleading: while the embed stuff should theoretically work because it now looks for the xlink:href first, the absref is still not updated. So, this bugs still happens (tested with 0.46). However: while it at least looks ugly to have some old references to other people's desktop locations there (information disclosure?) for eternity, simple changing these is also not possible. If you exchanges svg files frequently (let's say via a shared SVN server), every user who changes a single element of the SVG and saves would trigger an update of all the absrefs.

So, I would recommend to say that not changing the absref needlessly is a feature, not a bug. But someone might write a plugin similar to the "Embed all images..." plugin like "Update all absolute image references" and possibly "Convert absolute image references to relative image references", so it can be done on demand by a user.

Anyway, embedding of my images still does not work, but I have not figured out yet why that is (missing/misleading docbase comes to mind, it tries to access c:\Program Files\gif\bla.gif instead of c:\Documents And Settings\somewhere\gif\bla.gif). But that is a separate problem and is probably fixed in trunk and 0.47 prereleases now.

[su_v (suv-lp)]

@Malte - could you test with a recent prerelease or dev build? The python extension 'Embed all images…' has been fixed (bug #386069) to handle URIs correctly (now used instead of local path/file names - see bug #168484).

[jazzynico (jazzynico)]

0.47 no longer use sodipodi:absref, but xlink:href alone.
Changing the image link in its properties now work well, as well as embedimage.py.

[Malte Cornils (malte)]

Great! Unfortunately, I am not in any position to test on 0.47 pre-release builds now, but I will comment later/reopen if there remain issues. For now, thanks a lot!