[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-
bug#19373: 24.4; SVG images rendered via librsvg fail at displaying non-inline bitmap images
Tue, 16 Dec 2014 20:44:54 +0100
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)
Vasilij Schneidermann <email@example.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
> 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/'
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
> Best regards