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

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

[Vasilij Schneidermann]

I've recently tested Emacs' support for displaying SVG images that
contain bitmap images.  The test files used were
<http://dev.w3.org/SVG/profiles/1.1F2/test/svg/struct-image-04-t.svg>
and
<http://dev.w3.org/SVG/profiles/1.1F2/test/svg/struct-image-02-b.svg>.
The imagemagick backend displays both pictures flawlessly, but renders
transparency as white background which makes it unsuitable for my
purposes.  The librsvg backend appears to render transparency correctly,
however in the first example with inline bitmaps the first image isn't
displayed at all (which can be easily fixed by replacing "jpg" with
"jpeg" in its sources); in the second example the non-inline bitmap
isn't displayed either.  I've tried tracking down the reason for this
behavior and the only pointer I could find was that librsvg is using
the cairo library to embed the bitmap image.  Is there any obvious fix I
can apply to remedy this issue?



In GNU Emacs 24.4.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.14.3)
 of 2014-10-21 on bitzer.hoetzel.info
Windowing system distributor `The X.Org Foundation', version 11.0.11602000
System Description:	Arch Linux

Configured using:
 `configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=gtk3 --with-xft
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong
 --param=ssp-buffer-size=4' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x r e p o r t - e m <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
/usr/share/emacs/site-lisp/SuperCollider/tree-widget hides /usr/share/emacs/24.4/lisp/tree-widget

Features:
(shadow sort gnus-util mail-extr emacsbug message idna format-spec
rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util help-fns mail-prsvr mail-utils time-date tooltip
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 73812 6500)
 (symbols 48 17579 0)
 (miscs 40 77 163)
 (strings 32 9145 4185)
 (string-bytes 1 252188)
 (vectors 16 8986)
 (vector-slots 8 384469 17487)
 (floats 8 63 185)
 (intervals 56 216 4)
 (buffers 960 12)
 (heap 1024 45321 956))

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

[Ulf Jasper]

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

> I've recently tested Emacs' support for displaying SVG images that
> contain bitmap images.  The test files used were
> <http://dev.w3.org/SVG/profiles/1.1F2/test/svg/struct-image-04-t.svg>
> and
> <http://dev.w3.org/SVG/profiles/1.1F2/test/svg/struct-image-02-b.svg>.
> The imagemagick backend displays both pictures flawlessly, but renders
> transparency as white background which makes it unsuitable for my
> purposes.  The librsvg backend appears to render transparency correctly,
> however in the first example with inline bitmaps the first image isn't
> displayed at all (which can be easily fixed by replacing "jpg" with
> "jpeg" in its sources); in the second example the non-inline bitmap
> isn't displayed either.  I've tried tracking down the reason for this
> behavior and the only pointer I could find was that librsvg is using
> the cairo library to embed the bitmap image.  Is there any obvious fix I
> can apply to remedy this issue?

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

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?

Best,
Ulf

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

[Ulf Jasper]

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

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

[Ulf Jasper]

Ulf Jasper <ulf.jasper@web.de> writes:

> Vasilij Schneidermann <hurrus.durrus@gmail.com> writes:
>> 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.

This is rsvg bug 739682 "doesn't recognize mime type image/jpg" [1] and
not an Emacs problem.

>> "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.

This is related to rsvg bug 596114 "image refs are relative to curdir,
not .svg file" [2].  I just pushed a fix to master (c17c864) which
should fix this.

BTW: There is also rsvg bug 646618 "Remote images not supported" [3]
which explains why references to remote images are not displayed.

Best,
ulf


[1] https://bugzilla.gnome.org/show_bug.cgi?id=739682
[2] https://bugzilla.gnome.org/show_bug.cgi?id=596114
[3] https://bugzilla.gnome.org/show_bug.cgi?id=646618

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

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 17 Dec 2014 21:00:54 +0100, Ulf Jasper <ulf.jasper@web.de> said:

> This is related to rsvg bug 596114 "image refs are relative to
> curdir, not .svg file" [2].  I just pushed a fix to master (c17c864)
> which should fix this.

I suspect it is not appropriate to refer to buffer-local variables of
the current buffer inside image loading functions:

diff --git a/src/image.c b/src/image.c
index 1a2c0e2..0bebd45 100644

[snip]

@@ -8818,7 +8822,9 @@ svg_load (struct frame *f, struct image *img)
 	  image_error ("Invalid image data `%s'", data, Qnil);
 	  return 0;
 	}
-      success_p = svg_load_image (f, img, SDATA (data), SBYTES (data));
+      original_filename = BVAR (current_buffer, filename);
+      success_p = svg_load_image (f, img, SDATA (data), SBYTES (data),
+                                  SDATA(original_filename));
     }
 
   return success_p;

Maybe SVG image descriptors should accept the property `:base-uri' or
something?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

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

[Ulf Jasper]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

>>>>>> On Wed, 17 Dec 2014 21:00:54 +0100, Ulf Jasper <ulf.jasper@web.de> said:
>
>> This is related to rsvg bug 596114 "image refs are relative to
>> curdir, not .svg file" [2].  I just pushed a fix to master (c17c864)
>> which should fix this.
>
> I suspect it is not appropriate to refer to buffer-local variables of
> the current buffer inside image loading functions:

[...]

> Maybe SVG image descriptors should accept the property `:base-uri' or
> something?

Agreed.  That solution would be a much cleaner.  I was thinking about
that but chose the simpler solution instead.  As an explanation=excuse:
This was one of my first trips to the c-side of Emacs-land.  I still
feel unfamiliar with this area.

I shall add a property to svg image specs for holding the filename.

Best,
ulf

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

[Ulf Jasper]

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

> Thanks, I've rebuilt Emacs from HEAD and confirmed that the fix does
> indeed work for me.  I'd be happier if it were fixed upstream, but
> consider it rather unlikely to happen.

Thanks for confirming.  Closing.

ulf