Embed extension fails

Same bug on Windows Vista, rev. 21460.

Sorry for the grammar, translate on google ...

I have the same problem and managed to identify the problem>> in your case, the problem is here: "/home/nicolas/file:/export/Inkscape/BugTest/EmbedTest.png", delete "file:/export/Inkscape/BugTest/", then import any image located in the same directory as this image (EmbedTest.png) or herself, now try to embed. If you import a bitmap using the tool, rather than dragging and dropping the inkscape, it seems that Inkscape use that last accessed the directory and add "file: /" + directory to import the same again.

That really does not happen in version 0:46

yes, in Inkscape 0.46 when you import an image and save the file, the link is given as :
       sodipodi:absref="C:\WINDOWS\Temp\spiro_smooth.PNG"
       xlink:href="spiro_smooth.PNG" />

in the devel version, the same link is given as :
       xlink:href="file:///C:/WINDOWS/Temp/spiro_smooth.PNG" />

it is clear that the syntax for referring to the file has changed significantly since the release of 0.46. However, this syntax works perfectly well for other applications. I can type this file reference directly into IE8 and it works properly.

The same image in 0.46 is coded like that:
    <image
       sodipodi:absref="/export/Inkscape/BugTest/EmbedTest.png"
       xlink:href="EmbedTest.png" />

When I open the SVG created with 0.46 in the dev. version, I have no problem embedding it. The opposite is false...

I think the issue is related to the way Inkscape handle absolute paths in xlink:href attribute. The embedimage.py extension (lines 64-68) looks weird:

 if (href != None):
                if (os.path.isabs(href)):
                    path=os.path.realpath(href)
                else:
                    path=os.path.realpath(href)

1. href is handled as if it were a path (isn't it an URI?);
2. realpath is called when href is absolute or relative;
3. absolute path is always considered relative (isabs is always false), probably a consequence of 1.

I take a look at the Python doc and xlink specs.

Fix committed in rev. 21567.
Patch attached.

Now extract the path from the URI before using it (should remove file:// from the path).
Works well on Ubuntu 9.04.
Could someone test on another OS?
Thanks.

I will test on Vista

please also note the bug https://bugs.launchpad.net/inkscape/+bug/168484
I hope that I did not screwed things up.

Is this issue here only related to the python scipts? Is it correct in the inkscape generated files after importing images?
Could someone clarify pls.

Adib.

Same bug on Mac OS X, rev. 21525.
With 'embedimage.py' rev 21567, the extension now works as expected -> successfully embedding bitmap images.
thanks for the quick fix!

theAdib, I have tested some versions older (dec. 2008) than your fix, and the bug was already present. Thus this bug is probably not your fault :o)

[Translated in google]

The error persists on Vista, but he withdrew the "file :///". I see that the problem was not exactly this, it is the following>> to embed an image he should use only the address of the image, but he tries to incorporate the image using two addresses (working path + path of the image), resulting in failure. By embedding, I think you should only use the path of the image.

example: I dragged an image from the directory "C:\Users\Frank\Desktop\pictures\corrinha.jpg" and released within Inkscape. Soon after import the same image through the menu "import", both have the same failure when trying to embed >>

"In the xlink: href or sodipodi: absref attributes found, or they do not point to an existing file! Unable to embed image.

Sorry we could not locate C:\C:\Users\Frank\Desktop\photos\corrinha.jpg "

Thanks all for your tests.
Frank, I have access to a Vista computer later today. I'll try to find a way to fix it with win32.

Ok, let's try another one for Win32 with rev. 21571.
Tested with Ubuntu 9.04 and Vista SP1, and it looks good (SVG files created with 0.46 and dev, relative and absolute path tested).

I didn't find how to fix with os.path or urlparse and therefore I had to check the OS version and remove the unnecessary part of the string (the first 3 chars: '/C:') when the path is absolute.
Please tell me (or patch) if you have a cleaner fix.

[Translated in google]

Well, I try to be more detailed, maybe help you:

My _Vista is SP1.

The following tests were done >>

- I create an object and a copy to bitmap, after trying to embed it >> works;

- I create an object and a copy to bitmap, after the image properties, delete a part of the string path of the image, then try to embed it >> still works, When delete the entire string>> does not work (until then all well);

- Restart the Inkscape, drag an image from a directory to within Inkscape, I try to embed it >> does not work:

     "No xlink:href or sodipodi:absref attributes found, or they do not point to an existing file! Unable to embed image.
      Sorry we could not locate C:\C:\Users\Frank\Desktop\fotos\corrinha.jpg"

      Then try to remove the second "C:\" in image properties >> generates the failure of linkage, but even then I try to embed it >> does not work:

              "No xlink:href or sodipodi:absref attributes found, or they do not point to an existing file! Unable to embed image.
              Sorry we could not locate C:\inkscape-0.47\0.47trunk\inkscape\Users\Frank\Desktop\fotos\corrinha.jpg"

              see now that the first "C:\" was replaced by "C:\inkscape-0.47\0.47trunk\inkscape\"

- Ok, now restart again Inkscape and import the same image via the Import command, try to embed it >> does not work:

      "No xlink:href or sodipodi:absref attributes found, or they do not point to an existing file! Unable to embed image.
      Sorry we could not locate C:\C:\Users\Frank\Desktop\fotos\corrinha.jpg" (same result of previous test)

      In image properties I reduces all string of the path of the file to just the file name "corrinha.jpg" >> No failure on linkage and the image remains visible. I try to embed it >> works!

I hope it can help you with these details.

I will test it now in Win XP SP3, I will post the result here later.

Frank,

Thanks for your tests and details. That's more or less what I've found out too.
Could you please test with rev. 21571 (or newer)? I've committed a workaround that should work on XP and Vista.

Okay, I'm compiling the 21576 rev. In a minute put the result

I just downloaded the file from rev 21567. When I run it on Windows XP I get the error message :

No xlink:href or sodipodi:absref attributes found, or they do not point to an existing file! Unable to embed image.

Sorry we could not locate C:\C:\WINDOWS\Temp\spiro_smooth.PNG

sorry, it was rev 21571

JazzyNico, rev. 21571, continues with the same problems that the rev. earlier. Tested with the same procedures and in both OSs, Vista-SP1 and XP-SP3. I am compiling rev. 21580.

I think this will work in Windows if you replace :

            if os.name == 'nt' and href[1:1] == '/':
                href = href[3:0]

with this :

            if os.name == 'nt' and href[0] == '/':
                href = href[3:]

Oopps, I've committed on older (and very bad) test version of the file.
Rev. 21581 should now work (at last!).
Thanks.

OK JazzyNico, I will test, I'm compiling, thanks.

[Translated in google]

We are progressing, but the bug continues >>

Drag an image from unit in "C:\Users\Frank\Desktop\fotos\corrinha.jpg", for example, into inscape, I try to embed >> work;

Repeat the procedure, but from the drive "D:\principal\imagens\Linux\corporate_linux.jpg", for example, try to embed >> does not work:

"In the xlink: href or sodipodi: absref attributes found, or they do not point to an existing file! Unable to embed image.
Sorry we could not locate C:\principal\imagens\Linux\corporate_linux.jpg"

See the address in the error is "\principal\imagens\Linux\corporate_linux.jpg" is correct, but the drive is "C:\", is wrong. I think he is referring to the FIRST disk drive, the same error occurs if I try to embed all the images (located on different disks) at one time, it tries to reference all images in the first disk used (C:\); He remain in the disk drive of the first image imported by drag and drop method. When using by method import comand, he remains on the drive of the LAST imported image, for example: If I import three images from differents hard drives, "C:\", "D:\" and "F:\ "respectively, they remain in the drive"F:\", and he treats it as if all the images were in the drive" F:\", generating the error trying to embed the images only units located in"C:\"and "D:\" I hope have helped you;

Another fix in rev. 21583.

The bug you describe is due to href[3:], which cuts the drive letter. Now works with href[1:].
There was another bug related to escaped chars (C:\Documents%20and%20Settings\...) which needed to be unquoted (done with urllib.unquote).
I really hope this fix will be the last :)

Thanks for your tests and your patience!

Ok, I'm downloading to test...thank you...

Perfect, JazzyNico, good job! Tested by all possible methods, all worked. Thank you!

@JazzyNico - how difficult would it be to apply your patch to 'svg_and_media_zip_output.py'? It says in the comments
   "this is the first Python script ever created
    its based on embedimage.py"
and fails with a "Could not locate file: file:///…" error msg.

forgot to add: see bug #386664

@~suv, it's problably not too hard. I'll try to take a look later today.

The patch still doesn't quite fix things. Files that have % escape sequences (such as %20 for spaces) still aren't found. It does work after the %20's are changed to spaces with a text editor outside inkscape.

@Rick
Tested again on Ubuntu 9.04, Inkscape rev. 22184.
Embedded an image with xlink:href = file:///export/Inkscape/BugTest/Test%20espace/EmbedTest.png successfully. No need to replace %20 manually.
Which Inkscape version do you use?

Fedora 11's latest

inkscape-0.47-0.8.20090508svn.fc11.i586

I also found that in the 'Image Properties' dialog I could manually replace the %20 with a space and that worked as well.

Your package is a bit older than the patch.
There are more recent packages for Fedora (http://koji.fedoraproject.org/koji/packageinfo?packageID=2118). You can also compile the very last pre2 version sources (http://sourceforge.net/projects/inkscape/files/inkscape/) or download the extension from SVN (http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/share/extensions/embedimage.py) and replace the python file in /usr/share/inkscape/extensions (or your install directory).

Ahhh, I see the difference. I had applied the patch above in this bug.

But it looks like the committed version applied unquote() before assigning to href... the unquote() replaces the escape characters.

     def embedImage(self, node):
         xlink = node.get(inkex.addNS('href','xlink'))
         if xlink is None or xlink[:5] != 'data:':
             absref=node.get(inkex.addNS('absref','sodipodi'))
             url=urlparse.urlparse(xlink)
- href=url.path
+ href=urllib.unquote(url.path)
+ if os.name == 'nt' and href[0] == '/':
+ href = href[1:]
             path=''
             #path selection strategy:
             # 1. href if absolute
             # 2. realpath-ified href

Just a last update.... tested the latest Fedora build, which oddly isn't in Testing or Stable and everything works.

0.47pre4; Vista SP2 32 bits

Seems that with this pre-release it isn't yet fixed as I have the same problem with raster images located in folders using special characters in their names (letter with accent – French) and I receive the following message:

No xlink:href or sodipodi:absref attributes found, or they do not point to an existing file! Unable to embed image.
Traceback (most recent call last):
  File "C:\Program Files\Inkscape\share\extensions\embedimage.py", line 105, in <module>
    e.affect()
  File "C:\Program Files\Inkscape\share\extensions\inkex.py", line 207, in affect
    self.effect()
  File "C:\Program Files\Inkscape\share\extensions\embedimage.py", line 38, in effect
    self.embedAll(self.document)
  File "C:\Program Files\Inkscape\share\extensions\embedimage.py", line 52, in embedAll
    self.embedImage(node)
  File "C:\Program Files\Inkscape\share\extensions\embedimage.py", line 76, in embedImage
    inkex.errormsg(_("Sorry we could not locate %s") % path)
  File "C:\Program Files\Inkscape\share\extensions\inkex.py", line 86, in errormsg
    sys.stderr.write((str(msg) + "\n").encode("UTF-8"))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 38: ordinal not in range(128)

Moving the image to the root of the partition resolves the problem.

Confirmed. The extracted URL was not properly decoded.
It should be fixed with the attached version of the extension.
Tested on Windows XP and Ubuntu 9.04. Could someone else test before I submit the patch to the devlist for review?

Vista Business SP2 32 bits

It works !

For JPGs and PNGs with or without color profile embedded, in SVGs having or not a color profile fixed in them, selecting only the active raster or all images.

Many thanks JazzyNico !

Inkscape 0.46+devel r22521 on OS X 10.5.8, Python 2.6.2
Inkscape 0.47pre4 on OS X 10.5.8, Python 2.5.1

I can't reproduce the error with the old version: linked images with either accented characters in the file name ('lower-left-öäü.png') or french accented letters in the path name ('/imaginé-èàé/') are embedded without error! And the new version doesn't seem to make a difference.

the image link in the test file (new file, bitmap imported):

    <image
       y="59.54723"
       x="213.68111"
       id="image3146"
       height="300"
       width="300"
       xlink:href="file:///Volumes/blue/src/Inkscape/dev/launchpad/media_zip_output/imagine%CC%81-e%CC%80a%CC%80e%CC%81/upper-left.png" />

?

Weird. I've tested again on my dev computer (Ubuntu 9.04, Inkscape from SVN), it the old version work fine, even with French accents...
So it doesn't work on XP (SVN) and Ubuntu 9.04 (pre0.0 from PPA), but works fine on OS X and Ubuntu 9.04 (SVN).
Since the new version seems to work everywhere, it's probably safe to commit it anyway.

>doesn't work on Ubuntu 9.04 (pre0.0 from PPA)
that's based on r21549, right? That's from before your previous patches...
<http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/share/extensions/?view=log>

> doesn't work on XP (SVN)
combined with Eric's report (0.47pre4) points to a current win32 problem :(

>>doesn't work on Ubuntu 9.04 (pre0.0 from PPA)
>that's based on r21549, right? That's from before your previous patches...

Oh, I really need a rest.. :)

> combined with Eric's report (0.47pre4) points to a current win32 problem :(

Or a python 2.5.1 problem (arghhh!).

> Or a python 2.5.1 problem (arghhh!).
at least not on OS X (see comment #40 - I tested both python versions)

Forgot to attach a svn diff patch...

I'm working with 0.48 in win7. When linking images, I've noticed that relative references don't work when they contain "%20". Absolute references containing "%20" do work though. Should I report this bug somewhere else?