Image tag does not support SVG documents

Bug #168244 reported by Bug Importer on 2007-01-16
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Martin Owens
Declined for 0.46.x by Krzysztof Kosinski
Declined for 0.47.x by Krzysztof Kosinski
Declined for 0.48.x by Krzysztof Kosinski
Nominated for 0.91.x by Bertrand Petit
Declined for Old by Krzysztof Kosinski

Bug Description

When using the following tag in an SVG file opened in Inkscape:

<image id="impImg" x="0" y="0" width="20.6791" height="21.764219"

The image shows a red cross with "Linked Image Not Found."

xlink namespace is identified correctly. When I replace




the image displays correctly (obviously after exporting the glyph.svg
source to a glyph.png image).

Firefox also cannot display an <image> tag which references an SVG source
file, but they state this specifically on their "to do" list; I was unable
to find a similar indication for Inkscape.

Purpose is to have one SVG image containing a logo common to various
derived images (letterhead, splash screen, etc) and be able to edit just
the logo and it is automatically propogated to all images which reference
it. This should be possible and as near as I can tell my usage is compliant
with SVG specification.

Apologies if I am doing something wrong.

Peter McAllister
<email address hidden>

Bryce Harrington (bryce) wrote :

Originator: NO

Thanks, this sounds like a legit bug.

hash (hash-g) on 2007-12-08
Changed in inkscape:
status: New → Confirmed
Tom Davidson (tjd-mit) wrote :

This feature was added in Inkscape 0.45 (bug 171795). Can you still reproduce this problem?

Changed in inkscape:
status: Confirmed → Incomplete
sas (sas-sas) wrote :

I can reproduce this in Inkscape 0.46pre3.

I'll attach two files to demonstrate the problem. Put both files (example.svg and blue.svg) into the same directory, and open example.svg in Inkscape. The image should show a blue square in the middle, but instead shows a red cross with the words "Linked image not found". Batik Squiggle and the Adobe SVG Viewer both show the blue square.

sas (sas-sas) wrote :
prkos (prkos) wrote :

Confirmed on WinXP, built March 9th

Changed in inkscape:
status: Incomplete → Confirmed
Bertrand Petit (bp-lp) wrote :

This bug seems half fixed in 0.46. The referenced document is opened, parsed, rendered and inserted as a raster. This is not the behavior I expected.

I'm disapointed by the vector to raster conversion. I was expecting that we would be able to link to another SVG document, manipulate it as a whole block, render it at any desired bitmap resolution while leaving the referenced document outside of the referring one.

I'm not sure if I correctly interpret the specification of the _image_ element. My comment may thus be completely wrong.

Jaspervdg (jaspervdg) wrote :

Actually, I can't reproduce the half-way fix in SVN... I've put the test case posted above in the test repository in SVN, as well as one that transforms a (more complex) input to provide further checks. So from now on it will be possible to track progress at (takes a while to load).

su_v (suv-lp) wrote :

Inkscape 0.46+devel r22575 on OS X 10.5.8 shows the linked svg file as blue square (as described in comment #6), the status line says: "Image 200 x 200: blue.svg in root". But it isn't inserted as raster image - the XML Editor shows the image attribute 'xlink:href' with the value "blue.svg", not an embedded image with "data:image/png;base64,…"

su_v (suv-lp) wrote :

Screenshot of Inkscape 0.47pre4 on OS X 10.5.8, with 'example.svg' from comment #3, linking to 'blue.svg'.

peepo (j-chetwynd) wrote :

wfm 0.47pre4 OS X 10.5.8

propose closing

Bertrand Petit (bp-lp) wrote :

I agree with ~suv, if bug I fixed I we see it as it was initally reported. However 0.47pre4 still exhibits the half-fix that I reported in follow-up #6 (2008-09-29), so in disagreement with peepo and I think the bug is not yet fully fixed.

I will test this on a SVN checkout in a few days as suggested by Jaspervdg.

su_v (suv-lp) wrote :

@Bertrand - I think you misunderstood my comment - I cannot confirm the 'half-way' fix: there is *no* indication that the SVG file is inserted as *raster* image. To me this looks fixed both in 0.47pre4 and in a current build from SVN (r22575) on OS X 10.5.8.

Missing feature is a graphical interface to create these kind of image links (besides the XML editor).

Bertrand Petit (bp-lp) wrote :

I can confirm the half-fix status of this fix on SVN revision 22583.

I've made a simple demonstration of this: the outer.svg file contains just a line and an image reference to inner.svg which is the same line as in outer. The two are slightly displaced so that the difference in rendering can clearly be seen.

I expected that the aspect of the two lines would be identical. Alas, the line defined by inner.svg is pixelated.

Attached is a screenshot.

Bertrand Petit (bp-lp) wrote :
Bertrand Petit (bp-lp) wrote :
peepo (j-chetwynd) wrote :

#13 confirmed 0.47pre4 OS X 10.5.8

Bertrand what a simple and excellent test,
even at 50% the error is clear,

might this be a separate bug?

su_v (suv-lp) wrote :

Could the pixelated rendering of the linked svg image be be related to bug #461842 “Image filter effect using path has low resolution”?

Bertrand Petit (bp-lp) wrote :

@peepo If making my report a new bug is easier for your to manage it then you have a go. Please be sure to subscribe me to the new bug as this issue is paramount to a workflow I'm curently buiding.

@~suv You may be right, bug #461842 might be another manifestation of the same issue if the image filter uses the same pipeline as the image element.

sas (sas-sas) wrote :

This is still completely broken for me in Inkscape 0.47 under Windows XP. Both my test (comments #3 and #4) and Bertrand Petit's test (comments #13, #14 and #15) give a "Linked image not found" graphic.

I notice that the people who say it's completely broken are using Windows XP (or didn't specify an OS), while those who say it works at least partially are using OS X (or didn't specify an OS).

su_v (suv-lp) wrote :

@Bertrand - I think the rasterization bug is covered in Bug #171795 “Don't rasterize linked SVG with <image>” <> (which is still marked as 'Confirmed' and 'Wishlist') - no need to file a new report, maybe you could update that report with your example in comment #13-15?

@sas: yes, "Linked image not found" looks like a win32 only issue with recent Inkscape versions. Any linux users who could confirm this?

jazzynico (jazzynico) wrote :

No problem on Ubuntu 9.10, Inkscape 0.47pre4.

tags: added: win32
tags: removed: win32
su_v (suv-lp) wrote :

@Krzysztof - I don't understand why to remove 'win32'? This issue has not longer been reproduced on linux and osx, only on win32 platforms. The more generic request to implement linking SVG sources via the <image> element is bug #171544, the issue with rasterized rendering of linked SVG sources is bug #171795 - both apply to all supported platforms, whereas the failure to find the linked SVG source (bug #168244) is reported unsolved on windows platforms only.

Krzysztof Kosinski (tweenk) wrote :

I thought it's the same bug as #171795... Maybe it is a different bug after all.

sas (sas-sas) wrote :

Nobody has been able to reproduce this bug under OS X or Linux, so I'm restoring the win32 tag.

tags: added: win32
Martok (martok) wrote :

Still confirmed in 0.48-1 on Win32.

I think this bug would qualify for Crititcal, since it has the effect of basically breaking SVG conformance: the SVG spec says, a conformant renderer has to understand PNG, JPEG & SVG. win32-inkscape does not...

Koji Miyazato (viercc) wrote :

This information sounds relevant:

This is a link to archive of pygtk mailing list. First post in the page says,

> Quoting :
> > My pygtk app displays svg graphics. This works fine on Linux, but
> > displays nothing on Windows. This FAQ entry, though dated, confirms
> > my suspicions that PyGtk does not support SVG on Windows:
> > .
> The faq has been wrong for a long time, so I've removed that comment.
> I have to admit, however, that getting things working might not be
> obvious at first. For example, if you're using one of the "gtk+ bundles",
> you don't have the pixbuf-loader responsible for loading svg files
> (lib\gtk-2.0\2.10.0\loader\svg_loader.dll in your GTK+ installation).
> ,,,

Sorry if it is not correct for Inkscape.

Martok (martok) wrote :

The .dll library itself is present, but there is no mention of it in gtk+'s gdk-pixbuf.loaders cache file (which contains local paths of the build machine, btw)

Strangely enough, none of the do actually get loaded, as Process Monitor tells me. Since I'm missing the insight as to how the win32-version is built, that might be intentional or some kind of config gone haywire.

su_v (suv-lp) on 2011-09-25
tags: added: importing
su_v (suv-lp) wrote :

As far as I can tell, Inkscape does not use its internal renderer for the content of an <image> tag linking to an SVG file, but librsvg:

For a test, create a small file with a short flowed text, and link it in a second file via <image> tag: the flowed text will be rendered as black box (because it is an unsupported feature in any other SVG renderer except Inkscape).

Missing integration of librsvg as image handler (pixbuf-loader) in the windows package of Inkscape might be the underlying issue here (IIRC the separate 'About' icon in the Help menu fails for the same reason to be displayed in the Windows port).

summary: - image tag does not find SVG source
+ [win32] image tag does not find SVG source

Console message with 0.48.1:
** Message: error loading pixbuf at close

jazzynico (jazzynico) wrote :

librsvg is partially installed in the devlibs (some parts in lib and include seem to be missing), but apparently not linked in build.xml.

Library available in the gnome ftp:

su_v (suv-lp) wrote :

There is a recent packaging regression on Mac OS X as well:
The official Mac OS X package for Inkscape 0.48.2 misses the entry for SVG in 'etc/gtk-2.0/gdk-pixbuf.loaders' (included in the application bundle) and thus fails to load SVG files linked via <image> tag. The entry was present in earlier releases (e.g. 0.48.1).

The required library is present in the app bundle, and loading an SVG linked via <image> tag works fine after adding back the SVG entry into the gdk_pixbuf loaders configuration.

Note: The file 'gdk-pixbuf.loaders' is auto-generated when installing the dependencies for Inkscape:
> # Created by gdk-pixbuf-query-loaders from gdk-pixbuf-2.22.1
and I don't know why the entry for SVG is absent in the 0.48.2 package (it's present in all of my local installs).

--- gdk-pixbuf.loaders-0.48.1 2012-01-31 14:57:23.000000000 +0100
+++ gdk-pixbuf.loaders-0.48.2 2012-01-31 14:55:35.000000000 +0100
@@ -88,13 +88,6 @@
 "ras" ""
 "Y\246j\225" "" 100

-"svg" 2 "gdk-pixbuf" "Scalable Vector Graphics" "LGPL"
-"image/svg+xml" "image/svg" "image/svg-xml" "image/vnd.adobe.svg+xml" "text/xml-svg" ""
-"svg" ""
-" <svg" "* " 100
-" <!DOCTYPE svg" "* " 100
 "tga" 4 "gdk-pixbuf" "The Targa image format" "LGPL"
 "image/x-tga" ""

su_v (suv-lp) wrote :

Console message(s) with official package Inkscape 0.48.2 (unmodified) on Mac OS X 10.5.8 when trying to load a linked SVG file:

(inkscape-bin:15495): GdkPixbuf-CRITICAL **: gdk_pixbuf_loader_write: assertion `priv->closed == FALSE' failed

tags: added: osx
Ezmer DeKleaner (edekleaner) wrote :

An a first nest it works on Ubuntu. Fails on Mac OS.

so this structure works:

but, if the nested SVG has another SVG inside then it fails on linux (with no warning, no display of the lowest nested SVG)
(using image tag).


This should recurse until it runs out of stack space, (as well as monitoring for previously linked svg's).

Opera appears to do this correctly. This also fails on Webkit (Safari, Chrome) as well as Firefox

Changed in ubuntu:
status: New → Invalid

I can confirm the original problem is occurring in 0.48 on Mac OSX. I see no entry for the SVG Pixbuf importer in /Applications/ which would seem to be the most likely culprit.

su_v (suv-lp) on 2013-01-04
summary: - [win32] image tag does not find SVG source
+ [packaging] image tag does not find SVG source
su_v (suv-lp) on 2013-01-04
tags: added: packaging
Martin Owens (doctormo) on 2014-01-25
Changed in inkscape:
assignee: nobody → Martin Owens (doctormo)
Krzysztof Kosinski (tweenk) wrote :

Changing bug title - this bug should NOT be fixed by adding a SVG loader to the packaging, because this will cause the referenced SVG to be rasterized before display, and we don't want that.

summary: - [packaging] image tag does not find SVG source
+ Image tag does not support SVG documents
su_v (suv-lp) wrote :

On 2014-03-12 22:29 +0100, Krzysztof Kosinski wrote:
> Changing bug title - this bug should NOT be fixed by adding a SVG
> loader to the packaging, because this will cause the referenced SVG
> to be rasterized before display, and we don't want that.

The underlying issue is tracked in
- Bug #171795 “Don't rasterize linked SVG with <image>”:

AFAIU the two reports tracked related, but different issues: the underlying issue is bug #171795, whereas this one tracked issues with the current state (<img> references to SVG documents are rendered via gkd-pixbif loader) due to packaging of Inkscape outside of linux. If this report now gets reinterpreted as being about the underlying issue, I think it should better be marked as duplicate of bug #171795 (than having two separate reports now tracking the same underlying issue)

su_v (suv-lp) on 2014-11-06
tags: added: importingpackaging
removed: importing osx packaging
Martin Owens (doctormo) wrote :

I agree to the above assessment, this needs to be marked as a duplicate of bug #171795 since the gdtk-pixbf method isn;t coming back for the linux build.

su_v (suv-lp) on 2014-11-06
tags: added: importing packaging
removed: importingpackaging
su_v (suv-lp) wrote :

Linking as duplicate to bug #171795, which is still open for all supported platforms (the commit referenced in comment 38 had been reverted, and even on linux current Inkscape (0.91, 0.91+devel r13904) uses the Gdk-pixbuf loader to rasterize an SVG image linked via <image> tag).

The packaging issue on OS X has been resolved (fixed in packages for Inkscape 0.48.5 and 0.91), the packaging problem with librsvg and its gdk-pixbuf loader on Windows is now tracked in bug #1271938 (template preview image is affected by the same issue).

tags: removed: packaging win32
su_v (suv-lp) on 2015-02-06
no longer affects: inkscape-devlibs
William Cain (billctrcain) wrote :

This problem is still happening, and is a big problem for me (Trying to link to an external svg file causes the message in Inkscape "Linked image not found") - is there any new info I could provide to get work started to fix this. I am using Inkscape ver 0.92 on a windows 7 machine 64bit.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers