[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19373: 24.4; SVG images rendered via librsvg fail at displaying non-
From: |
Ulf Jasper |
Subject: |
bug#19373: 24.4; SVG images rendered via librsvg fail at displaying non-inline bitmap images |
Date: |
Tue, 16 Dec 2014 20:44:54 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
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