GNU bug report logs - #26978
25.2; incomplete display of SVG image

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 26978 in the body.
You can then email your comments to 26978 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: ynyaaa <at> gmail.com
To: bug-gnu-emacs <at> gnu.org
Subject: 25.2; incomplete display of SVG image
Date: Thu, 18 May 2017 13:24:40 +0900

(1)Texts in SVG are not displayed.
This sample should show "ABC" in a red square,
but three rectangles are displayed instead of "ABC".

<svg xmlns="http://www.w3.org/2000/svg" width="100" height="100">
  <rect fill="red" width="100" height="100"/>
  <text x="10" y="60" font-size="40" fill="white">ABC</text>
</svg>

(2)External image files may not be displayed.
Copy emacs-25.2/share/icons/hicolor/16x16/apps/emacs.png
into the same directory of the sample SVG,
I can view the scaled emacs icon over a blue square with image-mode.

If emacs.png and the SVG are saved in the root directory,
viewing the SVG shows only a blue square.

If emacs.png is not in the same directory of the SVG nor its descendant
and the path of xlink:href="..." is rewritten,
viewing the SVG shows only a blue square.

If the current buffer is not related to any file
(i.e. buffer-file-name is nil),
evaluating (insert-image (create-image data-string 'svg t))
shows only a blue square.

<svg xmlns="http://www.w3.org/2000/svg" width="100" height="100"
     xmlns:xlink="http://www.w3.org/1999/xlink">
  <rect fill="blue" width="100" height="100"/>
  <image xlink:href="emacs.png" width="100" height="100"/>
</svg>


I obtained librsvg-2.40.1-2-w32-bin.zip
from http://sourceforge.net/projects/ezwinports/files/.



In GNU Emacs 25.2.1 (i686-w64-mingw32)
 of 2017-04-25 built on LAPHROAIG
Windowing system distributor 'Microsoft Corp.', version 6.0.6002
Configured using:
 'configure --host=i686-w64-mingw32 --without-dbus
 --without-compress-install 'CFLAGS=-static -O2 -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: JPN
  locale-coding-system: cp932

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-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
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:

Load-path shadows:
None found.

Features:
(pp shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu
cl-loaddefs pcase cl-lib mail-prsvr mail-utils time-date mule-util
japan-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table w32-win w32-vars
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded 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
w32notify w32 multi-tty make-network-process emacs)

Memory information:
((conses 8 91787 12015)
 (symbols 32 19674 0)
 (miscs 32 58 179)
 (strings 16 15897 3822)
 (string-bytes 1 428454)
 (vectors 8 13073)
 (vector-slots 4 518142 10014)
 (floats 8 166 59)
 (intervals 28 219 37)
 (buffers 520 20))

Message #8 received at 26978 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: ynyaaa <at> gmail.com
Cc: 26978 <at> debbugs.gnu.org
Subject: Re: bug#26978: 25.2; incomplete display of SVG image
Date: Thu, 18 May 2017 07:55:43 +0300

> From: ynyaaa <at> gmail.com
> Date: Thu, 18 May 2017 13:24:40 +0900
> 
> (1)Texts in SVG are not displayed.
> This sample should show "ABC" in a red square,
> but three rectangles are displayed instead of "ABC".
> 
> <svg xmlns="http://www.w3.org/2000/svg" width="100" height="100">
>   <rect fill="red" width="100" height="100"/>
>   <text x="10" y="60" font-size="40" fill="white">ABC</text>
> </svg>

I cannot reproduce this: I do see "ABC" in a red square.

> (2)External image files may not be displayed.
> Copy emacs-25.2/share/icons/hicolor/16x16/apps/emacs.png
> into the same directory of the sample SVG,
> I can view the scaled emacs icon over a blue square with image-mode.
> 
> If emacs.png and the SVG are saved in the root directory,
> viewing the SVG shows only a blue square.
> 
> If emacs.png is not in the same directory of the SVG nor its descendant
> and the path of xlink:href="..." is rewritten,
> viewing the SVG shows only a blue square.

Is this related to the first or the second SVG in your report?

> If the current buffer is not related to any file
> (i.e. buffer-file-name is nil),
> evaluating (insert-image (create-image data-string 'svg t))
> shows only a blue square.
> 
> <svg xmlns="http://www.w3.org/2000/svg" width="100" height="100"
>      xmlns:xlink="http://www.w3.org/1999/xlink">
>   <rect fill="blue" width="100" height="100"/>
>   <image xlink:href="emacs.png" width="100" height="100"/>
> </svg>

Here I see only a blue square no matter whether this SVG is from a
file or from a buffer string, and no matter what is the directory.
Once again, a full detailed recipe could help establish whether
there's a difference between our systems.

Can someone please try the above SVG on a Unix or GNU system and see
what is shown?

This could also be a problem with that particular version of librsvg,
which would make it not an Emacs problem.

> I obtained librsvg-2.40.1-2-w32-bin.zip
> from http://sourceforge.net/projects/ezwinports/files/.

What about the PNG library?  Is it possible you are using one that is
different from what came with librsvg-2.40.1-2-w32-bin.zip?  librsvg
uses libpng internally.

Message #11 received at 26978 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: ynyaaa <at> gmail.com
Cc: 26978 <at> debbugs.gnu.org
Subject: Re: bug#26978: 25.2; incomplete display of SVG image
Date: Thu, 18 May 2017 08:19:37 +0300

> From: ynyaaa <at> gmail.com
> Date: Thu, 18 May 2017 13:24:40 +0900
> 
> (1)Texts in SVG are not displayed.
> This sample should show "ABC" in a red square,
> but three rectangles are displayed instead of "ABC".
> 
> <svg xmlns="http://www.w3.org/2000/svg" width="100" height="100">
>   <rect fill="red" width="100" height="100"/>
>   <text x="10" y="60" font-size="40" fill="white">ABC</text>
> </svg>

I cannot reproduce this: I do see "ABC" in a red square.

> (2)External image files may not be displayed.
> Copy emacs-25.2/share/icons/hicolor/16x16/apps/emacs.png
> into the same directory of the sample SVG,
> I can view the scaled emacs icon over a blue square with image-mode.
> 
> If emacs.png and the SVG are saved in the root directory,
> viewing the SVG shows only a blue square.
> 
> If emacs.png is not in the same directory of the SVG nor its descendant
> and the path of xlink:href="..." is rewritten,
> viewing the SVG shows only a blue square.

Is this related to the first or the second SVG in your report?

> If the current buffer is not related to any file
> (i.e. buffer-file-name is nil),
> evaluating (insert-image (create-image data-string 'svg t))
> shows only a blue square.
> 
> <svg xmlns="http://www.w3.org/2000/svg" width="100" height="100"
>      xmlns:xlink="http://www.w3.org/1999/xlink">
>   <rect fill="blue" width="100" height="100"/>
>   <image xlink:href="emacs.png" width="100" height="100"/>
> </svg>

Here I see only a blue square no matter whether this SVG is from a
file or from a buffer string, and no matter what is the directory.
Once again, a full detailed recipe could help establish whether
there's a difference between our systems.

Firefox does show the PNG image on the background of the square.  Can
someone please try the above SVG in Emacs on a Unix or GNU system and
tell what is displayed?

This could be a problem with that particular version of librsvg, which
would make it not an Emacs problem.

> I obtained librsvg-2.40.1-2-w32-bin.zip
> from http://sourceforge.net/projects/ezwinports/files/.

What about the PNG library?  Is it possible you are using one that is
different from what came with librsvg-2.40.1-2-w32-bin.zip?  librsvg
uses libpng internally.

Message #14 received at 26978 <at> debbugs.gnu.org (full text, mbox):

From: ynyaaa <at> gmail.com
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 26978 <at> debbugs.gnu.org
Subject: Re: bug#26978: 25.2; incomplete display of SVG image
Date: Thu, 18 May 2017 19:02:18 +0900

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

> Once again, a full detailed recipe could help establish whether
> there's a difference between our systems.

The attached tgz file contains
  test-svg/appearance-abc.png
  test-svg/appearance-png.png
  test-svg/appearance-subdir.png
  test-svg/emacs.png
  test-svg/sample-abc.svg
  test-svg/sample-png.svg
  test-svg/subdir/sample-subdir.svg

test-svg/appearance-*.png are screen shots when viewing SVG files
by C-x C-f.

test-svg/appearance-abc.png is for test-svg/sample-abc.svg
(three rectangles instead of "ABC").

test-svg/appearance-png.png is for test-svg/sample-png.svg
(a scaled emacs icon, expected image).

test-svg/appearance-subdir.png is for test-svg/subdir/sample-subdir.svg
(a blue square without the emacs icon, unexpected image).

Type C-x C-f test-svg/sample-png.svg
and evaluate (setq buffer-file-name nil)
and type C-c C-c C-c C-c(image-toggle-display twice),
then the image looks same as test-svg/appearance-subdir.png.

>> I obtained librsvg-2.40.1-2-w32-bin.zip
>> from http://sourceforge.net/projects/ezwinports/files/.
>
> What about the PNG library?  Is it possible you are using one that is
> different from what came with librsvg-2.40.1-2-w32-bin.zip?  librsvg
> uses libpng internally.

I copied bin/*.dll files in librsvg-2.40.1-2-w32-bin.zip
into emacs bin directory, including libpng16-16.dll.
  bin/libcairo-2.dll
  bin/libcroco-0.6-3.dll
  bin/libffi-6.dll
  bin/libgdk_pixbuf-2.0-0.dll
  bin/libgio-2.0-0.dll
  bin/libglib-2.0-0.dll
  bin/libgmodule-2.0-0.dll
  bin/libgobject-2.0-0.dll
  bin/libiconv-2.dll
  bin/libintl-8.dll
  bin/libpango-1.0-0.dll
  bin/libpangocairo-1.0-0.dll
  bin/libpangowin32-1.0-0.dll
  bin/libpixman-1-0.dll
  bin/libpng16-16.dll
  bin/librsvg-2-2.dll
  bin/libxml2-2.dll
  bin/zlib1.dll

[test-svg.tgz (application/octet-stream, attachment)]

Message #17 received at 26978 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: ynyaaa <at> gmail.com
Cc: 26978 <at> debbugs.gnu.org
Subject: Re: bug#26978: 25.2; incomplete display of SVG image
Date: Thu, 18 May 2017 18:34:45 +0300

> From: ynyaaa <at> gmail.com
> Cc: 26978 <at> debbugs.gnu.org
> Date: Thu, 18 May 2017 19:02:18 +0900
> 
> The attached tgz file contains
>   test-svg/appearance-abc.png
>   test-svg/appearance-png.png
>   test-svg/appearance-subdir.png
>   test-svg/emacs.png
>   test-svg/sample-abc.svg
>   test-svg/sample-png.svg
>   test-svg/subdir/sample-subdir.svg
> 
> test-svg/appearance-*.png are screen shots when viewing SVG files
> by C-x C-f.
> 
> test-svg/appearance-abc.png is for test-svg/sample-abc.svg
> (three rectangles instead of "ABC").

This most probably means you don't have some font installed.  On my
system, this file displays correctly.

> test-svg/appearance-png.png is for test-svg/sample-png.svg
> (a scaled emacs icon, expected image).
> 
> test-svg/appearance-subdir.png is for test-svg/subdir/sample-subdir.svg
> (a blue square without the emacs icon, unexpected image).
> 
> Type C-x C-f test-svg/sample-png.svg
> and evaluate (setq buffer-file-name nil)
> and type C-c C-c C-c C-c(image-toggle-display twice),
> then the image looks same as test-svg/appearance-subdir.png.

This one displays fine on one system I tried, but not on another.  So
I think it's some subtle problem with librsvg.

Message #20 received at 26978 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: ynyaaa <at> gmail.com
Cc: Eli Zaretskii <eliz <at> gnu.org>, 26978 <at> debbugs.gnu.org
Subject: Re: bug#26978: 25.2; incomplete display of SVG image
Date: Thu, 26 Sep 2019 17:37:10 +0200

ynyaaa <at> gmail.com writes:

> test-svg/appearance-png.png is for test-svg/sample-png.svg
> (a scaled emacs icon, expected image).

The file is:

<svg xmlns="http://www.w3.org/2000/svg" width="100" height="100"
     xmlns:xlink="http://www.w3.org/1999/xlink">
  <rect fill="blue" width="100" height="100"/>
  <image xlink:href="emacs.png" width="100" height="100"/>
</svg>

If we change that to an absolute path (and add the "file://" bit), it
does display correctly here on this Debian Buster machine:

<svg xmlns="http://www.w3.org/2000/svg" width="100" height="100"
     xmlns:xlink="http://www.w3.org/1999/xlink">
  <rect fill="blue" width="100" height="100"/>
  <image xlink:href="file:///tmp/test-svg/emacs.png" width="100" height="100"/>
</svg>

As Eli says, it's probably due to differences in SVG libraries and what
they allow.  But interestingly enough, using "display" on the original
file works, and "display" uses rsvg, too.  (Emacs uses rsvg, right?)

So I'm wondering whether there's something we can tell the rsvg library
to make it find these sub-images, or something.  I mean, we could also
pre-process the SVG files, but that's more than a bit hacky...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #23 received at 26978 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: ynyaaa <at> gmail.com
Cc: Eli Zaretskii <eliz <at> gnu.org>, 26978 <at> debbugs.gnu.org
Subject: Re: bug#26978: 25.2; incomplete display of SVG image
Date: Thu, 26 Sep 2019 17:50:22 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> So I'm wondering whether there's something we can tell the rsvg library
> to make it find these sub-images, or something. 

This works correctly:

(insert-image (create-image "/tmp/test-svg/sample-png.svg"))

The problem is that when you C-x C-f the image, then this code fails,
sort of::

static bool
svg_load (struct frame *f, struct image *img)
{
  bool success_p = 0;
  Lisp_Object file_name;

  /* If IMG->spec specifies a file name, create a non-file spec from it.  */
  file_name = image_spec_value (img->spec, QCfile, NULL);
  if (STRINGP (file_name))

Because the image is in the buffer already, we don't tell the rsvg
library what the file name is, and so it can't find the sub-images in
question.

Hm...  hang on...  I'm getting spurious results here.  I think
image-mode is supposed to pass the file name into create-image in most
cases...  but I'm getting sporadic failures: Sometimes it works and
sometimes it doesn't.  Can't see any pattern, really.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #26 received at 26978 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: ynyaaa <at> gmail.com
Cc: Eli Zaretskii <eliz <at> gnu.org>, 26978 <at> debbugs.gnu.org
Subject: Re: bug#26978: 25.2; incomplete display of SVG image
Date: Thu, 26 Sep 2019 17:53:42 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Hm...  hang on...  I'm getting spurious results here.  I think
> image-mode is supposed to pass the file name into create-image in most
> cases...  but I'm getting sporadic failures: Sometimes it works and
> sometimes it doesn't.  Can't see any pattern, really.

OK, I've now tested with an ImageMagick-enabled Emacs and without.  The
ImageMagick one fails spuriously.  The one without always works,
apparently.

So I think this bug has been fixed in the current rsvg library versions
on Debian, at least.  In any case, I think Emacs does everything right
here, so I'm closing this bug report.  Please reopen if there's still
something to be done here.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.