bug#19373: 24.4; SVG images rendered via librsvg fail at displaying non-inline bitmap images

[Ulf Jasper <ulf.jasper@web.de>]

Vasilij Schneidermann <hurrus.durrus@gmail.com> writes:

> On 12/16/14 at 07:28pm, Ulf Jasper wrote:
>> rsvg-view (called rsvg-view-3 on debian), which is librsvg's standalone
>> svg-viewer, shows the same behaviour:
>> 
>>  - the referenced image in struct-image-02-b.svg is not shown
>>  - the embedded=inlined jpg image in struct-image-04-t.svg is not shown
>
> FWIW, I have `rsvg-view-3` on my Arch Linux system, too.  If I go ahead
> and download the referenced files to view them with it as they come, I
> get the same symptoms as you have described.  However, with minor
> "workarounds" I can get them to display.
>
> For "struct-image-04-t.svg" the following `sed` invocation is sufficient:
>
>     sed -i 's/data:image\/jpg/data:image\/jpeg/' struct-image-04-t.svg

I can confirm that the modified svg-file displays correctly, both, with
rsvg-view-3 as well as with Emacs (master): The embedded=inlined
jpg=jpeg and the png image are both shown.  So rsvg-view-3 and Emacs
show the same behaviour for original and modified file.

> "struct-image-02-b.svg" requires a bit more work because it references
> an image on the w3.org servers.  Assuming you download the referenced
> image at
> <http://dev.w3.org/SVG/profiles/1.1F2/test/images/struct-image-02.jpg>
> and save it as "struct-image-02.jpg" in the same directory as
> "struct-image-02-b.svg", you can edit the path to it with the following
> `sed` call:
>
>     sed -i 's/..\/images\/struct-image-02.jpg/struct-image-02.jpg/' struct-image-02-b.svg

Here I see a difference between rsvg-view-3 and Emacs.  rsvg-view-3
displays the modified file correctly, i.e. it shows the referenced file,
while Emacs still does not show the referenced file.

>> So this looks like an librsvg issue and probably is not related to
>> Emacs.  Maybe you could ask on the librsvg mailing list about this?
>  
> These two "workarounds" allow me to display both test files as intended,
> therefore I believe it's not librsvg's fault.  For ease of testing I've
> attached all files necessary for testing to this message.  Could other
> people please check whether they can reproduce anything with their
> systems?
>
> Best regards
> Vasilij