Please can you some reproduction code, and an SVG image(s) that shows this issue.

Waiting feedback.

OK, quick demonstration:
First SVG (green.svg) is a green square, 80x80 in a 100x100 viewbox.
Second SVG (red.svg) is a red square as above, but with the first SVG linked as an image, shrunk to fit within the square.


<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg xmlns="http://www.w3.org/2000/svg" xml:space="preserve" width="100" height="100" viewBox="0 0 100 100" xmlns:xlink="http://www.w3.org/1999/xlink">
<rect x="10" y="10" width="80" height="80" fill="green"/>
</svg>


<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg xmlns="http://www.w3.org/2000/svg" xml:space="preserve" width="100" height="100" viewBox="0 0 100 100" xmlns:xlink="http://www.w3.org/1999/xlink">
<rect x="10" y="10" width="80" height="80" fill="red"/>
<image x="30" y="30" width="40" height="40" xlink:href="green.svg" preserveAspectRatio="xMidYMid meet"/>
</svg>



Code running imagick:
<?php
$svgpath ='red.svg';
$img = new Imagick();
$svg = file_get_contents($svgpath);
echo $svg;
$img->setBackgroundColor("none");
$img->readImageBlob($svg);
$img->setImageFormat("png32");
$img->writeImage('./generated/red.png');
$embed=base64_encode($img);
echo '<img src="data:image/png;base64,'.$embed.'"/>'; 
?>

Results in the original SVG displayed, alongside the output png which simply shows the red square, not the red square with a green square contained within.


Using inkscape from command-line correctly outputs this, though using imagick would be greatly preferred.
passthru("inkscape -z --file=red.svg --export-png=generated/red.png");

Are you sure this is a PHP IMagick issue and not just an issue with ImageMagick in general? If you install the standalone ImageMagick utilities, do they work?

So just to confirm - the image './generated/red.png' looks correct to you and it's just the image displayed directly that is wrong? That is what it appears to me, I just wanted to confirm before investigating further.

@ajf The imagick code is really a very simple wrapper around the ImageMagick library....almost all of the issue people have are due to the underlying library, but the behaviour of the command line utilities isn't the same as calling code through the API interface...so it's very likely to be the case that there's nothing in Imagick to fix, but as a responsible and bearded maintainer, I'll still need to figure out the issue and report it upstream.

Imagemagick from command line correctly processes the linked images.
Sorry, I should have added this line to the previous post.

passthru("convert -background none red.svg generated/red.png");

Results in the correct output.

The image that php5-imagick is generating does not include the linked images.

ImageMagick convert from command-line and Inkscape all display as they should.

So I've done some investigation and the issue is that the underlying ImageMagick library does not appear to read the relative images. It's looking in the current directory for the linked images, instead of the directory where the first image is located. I've asked the ImageMagick developers to clarify what is meant to be supported:

http://www.imagemagick.org/discourse-server/viewtopic.php?f=1&t=26837

If you're not using the Zend thread safe version of PHP, you may be able to `chdir` into the directory where the first image is located, but that does not work in the ZTS version of PHP, as chdir only affects PHP userland code - not underlying libraries.

There is also another issue in that ImageMagick library should be throwing an exception, rather than generating an image that is missing some pieces; I'll open that separately.

Hi,

It looks like this is a bug in the program being used by ImageMagick to do the conversion. You appear to have Inkscape installed on your system. This was a bug in Inkscape until version 0.48 https://bugs.launchpad.net/inkscape/+bug/386069 . If you are using Inkscape can you upgrade to at least that version (though preferably later) and see if the bug still exists.

Also please note, I don't think using plain filename for a relative filename is 100% valid. I believe the syntax should be more like `xlink:href="file://./green.svg"`, though I find the SVG documentation quite confusing, so could be wrong.


> Using inkscape from command-line correctly outputs this
> passthru("inkscape -z --file=red.svg --export-png=generated/red.png");

The reason why that works is that you're running the command in the same directory as the images, so when it looks in the current directory it finds the image.

The test I used is below. It runs from the command line but loads the images from a sub-directory. Please can you use something similar when testing?


=========================

read -d '' red << EOF
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg xmlns="http://www.w3.org/2000/svg" xml:space="preserve" width="100" height="100" viewBox="0 0 100 100" xmlns:xlink="http://www.w3.org/1999/xlink">
<rect x="10" y="10" width="80" height="80" fill="red"/>
<image x="30" y="30" width="40" height="40" xlink:href="green.svg" preserveAspectRatio="xMidYMid meet"/>
</svg>
EOF

read -d '' green << EOF
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg xmlns="http://www.w3.org/2000/svg" xml:space="preserve" width="100" height="100" viewBox="0 0 100 100" xmlns:xlink="http://www.w3.org/1999/xlink">
<rect x="10" y="10" width="80" height="80" fill="green"/>
</svg>
EOF

mkdir "svgSubDir"

echo $red > "svgSubDir/red.svg"
echo $green > "svgSubDir/green.svg"

convert -verbose svgSubDir/red.svg test.png

# output is:
# convert: unable to open image `green.svg': No such file or directory @ error/blob.c/OpenBlob/2709.

cd svgSubDir

convert -verbose red.svg testInSubdir.png

I have InkScape 0.48-4-2 (r9939) I believe. 
My convert uses RSVG, so I'm not getting any errors using -verbose.
convert -list format for SVG is Scalable Vector Graphics (RSVG 2.36.4).
librsvg version is listed at 2.40.0-1

There is definitely directory related mayhem going on.

When running from Terminal using a subdirectory, I ran with an absolute url, file relative path and plain filename. The plain filename was the only that rendered correctly.

When running the code from a subdirectory with images in the parent directory, funnily enough both ImageMagick and Inkscape rendered correctly but the original SVG wouldn't... Nor would imagick.

So.....this doesn't appear to be an issue with Imagick aka I'm not going to be able to fix it as it's a problem with the underlying libraries.

If ImageMagick is using RSVG then opening an issue at: https://bugzilla.gnome.org/buglist.cgi?quicksearch=rsvg+file would be good.

There actually is an open issue similar to yours: https://bugzilla.gnome.org/show_bug.cgi?id=596114 opened a mere 4 years ago.

Feel free to ask any other questions if you think we might be able to help, or otherwise keep this ticket updated,