GNU bug report logs -
#55322
28.1; :base-uri not working for svg images on mac
Previous Next
Reported by: Howard Melman <hmelman <at> gmail.com>
Date: Sun, 8 May 2022 19:17:02 UTC
Severity: normal
Found in version 28.1
Done: Alan Third <alan <at> idiocy.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 55322 in the body.
You can then email your comments to 55322 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55322
; Package
emacs
.
(Sun, 08 May 2022 19:17:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Howard Melman <hmelman <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sun, 08 May 2022 19:17:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Please forgive this bug report, I'm a bit out of my depth on the
technologies here but I'm trying.
I found this on the macport of Emacs 28.1 but it fails in a similar
though slightly different way on vanilla emacs 28.1 -Q. from
https://emacsformacosx.com/
I only know how to reproduce this with the osm package available from
GNU ELPA or https://github.com/minad/osm This renders maps from open
street maps inside emacs. It requires the package compat.
To reproduce, load the package compat and then osm (just osm.elc) and
do M-x osm-search and enter a place with completion, I used London for
this example. In Emacs 28.1 -Q it renders as follows:
The issue is that one of the tiles isn't being rendered. osm displays an svg
location marker at the searched for location and displays the map tile
behind that. On the macport it renders as follows which I think exposes
the issue more clearly:
In Emacs 27, osm displays this tile just fine because it included
the tile image as base64 encoded data because :base-uri
functionality didn't exist. As of Emacs 28 it tries to use it
for performance reasons an apparently it works fine on
linux systems. This can be found on line 929 of osm.el
The text of the image can be obtained via (buffer-string) in
the *osm* buffer. For the above I see (with a few newlines
added for clarity)::
#("
" 0 1 (display ((slice 170 194 86 62) (image :width 256 :height 256 :file "/Users/hmelman/.emacs.d/var/osm/default/9-254-169.png" :type png)))
1 2 (display ((slice 0 194 256 62) (image :width 256 :height 256 :file "/Users/hmelman/.emacs.d/var/osm/default/9-255-169.png" :type png)))
2 3 (display ((slice 0 194 256 62) (image :width 256 :height 256 :file "/Users/hmelman/.emacs.d/var/osm/default/9-256-169.png" :type png)))
3 4 (display ((slice 0 194 256 62) (image :width 256 :height 256 :file "/Users/hmelman/.emacs.d/var/osm/default/9-257-169.png" :type png)))
5 6 (display ((slice 170 0 86 256) (image :width 256 :height 256 :file "/Users/hmelman/.emacs.d/var/osm/default/9-254-170.png" :type png)))
6 7 (display (image :width 256 :height 256 :type svg :base-uri "/Users/hmelman/.emacs.d/var/osm/default/9-255-170.png" :data "<svg width='256' height='256' version='1.1'
xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink'>
<image xlink:href='9-255-170.png' height='256' width='256'/>
<g fill='#08f' stroke='#028' stroke-width='9' transform='translate(209 64) scale(0.09) translate(-256 -512)'>
<path d='M256 0C167.641 0 96 71.625 96 160c0 24.75 5.625 48.219 15.672
69.125C112.234 230.313 256 512 256 512l142.594-279.375
C409.719 210.844 416 186.156 416 160C416 71.625 344.375
0 256 0z M256 256c-53.016 0-96-43-96-96s42.984-96 96-96
c53 0 96 43 96 96S309 256 256 256z'/>
</g></svg>" :map (((poly . [209 64 189 24 209 14 229 24]) osm-transient (help-echo "London, Westminster, Greater London, En…" pointer hand)))
)) 7 8 (display (image :width 256 :height 256 :file "/Users/hmelman/.emacs.d/var/osm/default/9-256-170.png" :type png)) 8 9 (display (image :width 256 :height 256 :file "/Users/hmelman/.emacs.d/var/osm/default/9-257-170.png" :type png)))
The issue is the image referenced as:
xlink:href='9-255-170.png'
isn't found even though it is in the directory
/Users/hmelman/.emacs.d/var/osm/default/
Apparently this works fine on linux. I originally reported
it here: https://github.com/minad/osm/issues/23
I believe the emacs from https://emacsformacosx.com/
uses librsvg and the macport uses Webkit instead for
the rendering svg, but both fail, so I think it's in whatever
is handling :base-uri.
I don't know how to use the svg.el library but the
equivalent is apparently done via svg-embed-base-uri-image.
Is there a test case I could run via that to generate a
simpler recipe?
Can anyone else verify the use of :base-uri on a mac?
--
Howard
[Message part 2 (text/html, inline)]
[Screen Shot 2022-05-08 at 3.02.49 PM.png (image/png, inline)]
[Screen Shot 2022-05-08 at 3.03.52 PM.png (image/png, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55322
; Package
emacs
.
(Mon, 09 May 2022 03:33:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 55322 <at> debbugs.gnu.org (full text, mbox):
Howard Melman <hmelman <at> gmail.com> writes:
> Please forgive this bug report, I'm a bit out of my depth on the
> technologies here but I'm trying.
>
> I found this on the macport of Emacs 28.1 but it fails in a similar
> though slightly different way on vanilla emacs 28.1 -Q. from
> https://emacsformacosx.com/
>
> I only know how to reproduce this with the osm package available from
> GNU ELPA or https://github.com/minad/osm This renders maps from open
> street maps inside emacs. It requires the package compat.
>
> To reproduce, load the package compat and then osm (just osm.elc) and
> do M-x osm-search and enter a place with completion, I used London for
> this example. In Emacs 28.1 -Q it renders as follows:
This might very well be a different bug, since I don't see the location
marker being displayed on top, but instead I see "garbled" display.
What happens if you set a breakpoint in GDB on this piece of code in
image.c?
/* Set base_uri for properly handling referenced images (via 'href').
Can be explicitly specified using `:base_uri' image property.
See rsvg bug 596114 - "image refs are relative to curdir, not .svg file"
<https://gitlab.gnome.org/GNOME/librsvg/issues/33>. */
if (filename)
rsvg_handle_set_base_uri (rsvg_handle, filename);
Is it triggered? And if so, what is the value of `filename'?
> The issue is that one of the tiles isn't being rendered. osm displays
> an svg location marker at the searched for location and displays the
> map tile behind that. On the macport it renders as follows which I
> think exposes the issue more clearly:
It's not useful to compare the code in Carbon Emacs with the code in
Emacs.app. They use completely different code paths to handle the
`base-uri' attribute.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55322
; Package
emacs
.
(Mon, 09 May 2022 14:27:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 55322 <at> debbugs.gnu.org (full text, mbox):
> On May 8, 2022, at 11:32 PM, Po Lu <luangruo <at> yahoo.com> wrote:
>
> What happens if you set a breakpoint in GDB on this piece of code in
> image.c?
>
> /* Set base_uri for properly handling referenced images (via 'href').
> Can be explicitly specified using `:base_uri' image property.
> See rsvg bug 596114 - "image refs are relative to curdir, not .svg file"
> <https://gitlab.gnome.org/GNOME/librsvg/issues/33>. */
> if (filename)
> rsvg_handle_set_base_uri (rsvg_handle, filename);
>
> Is it triggered? And if so, what is the value of `filename'?
I'm hoping someone else can try this. It's been a long time since I've
used gdb, I don't have it installed now, and don't have emacs c source
installed as I don't build my own emacs.
> It's not useful to compare the code in Carbon Emacs with the code in
> Emacs.app. They use completely different code paths to handle the
> `base-uri' attribute.
I understand. I'm a macport user, first saw the issue there, and then
recreated it on Emacs.app. I know the paths are different, they both
fail here, I didn't know why and reported them as distinctly as I could.
That did turn out to be useful because @mituharu reported that
compiling the macport w/ librsvg works.
https://github.com/minad/osm/issues/23#issuecomment-1121032499
Howard
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55322
; Package
emacs
.
(Mon, 09 May 2022 21:43:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 55322 <at> debbugs.gnu.org (full text, mbox):
On Sun, May 08, 2022 at 03:16:02PM -0400, Howard Melman wrote:
> 6 7 (display (image :width 256 :height 256 :type svg :base-uri "/Users/hmelman/.emacs.d/var/osm/default/9-255-170.png" :data "<svg width='256' height='256' version='1.1'
> xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink'>
> <image xlink:href='9-255-170.png' height='256' width='256'/>
> <g fill='#08f' stroke='#028' stroke-width='9' transform='translate(209 64) scale(0.09) translate(-256 -512)'>
> <path d='M256 0C167.641 0 96 71.625 96 160c0 24.75 5.625 48.219 15.672
> 69.125C112.234 230.313 256 512 256 512l142.594-279.375
> C409.719 210.844 416 186.156 416 160C416 71.625 344.375
> 0 256 0z M256 256c-53.016 0-96-43-96-96s42.984-96 96-96
> c53 0 96 43 96 96S309 256 256 256z'/>
> </g></svg>"
The above image should be able to be replicated with something like
this below:
(insert-image (create-image "<svg width='256' height='256' version='1.1'
xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink'>
<image xlink:href='9-255-170.png' height='256' width='256'/>
<g fill='#08f' stroke='#028' stroke-width='9'
transform='translate(209 64) scale(0.09) translate(-256 -512)'>
<path d='M256 0C167.641 0 96 71.625 96 160c0 24.75 5.625 48.219 15.672
69.125C112.234 230.313 256 512 256 512l142.594-279.375
C409.719 210.844 416 186.156 416 160C416 71.625 344.375
0 256 0z M256 256c-53.016 0-96-43-96-96s42.984-96 96-96
c53 0 96 43 96 96S309 256 256 256z'/></g></svg>"
'svg t :width 256 :height 256
:base-uri "/Users/hmelman/.emacs.d/var/osm/default/9-255-170.png"))
Try messing with the base-uri, perhaps try setting it to the
directory, or to foo.svg or something.
My first guess would be that if it's working on GNU/Linux but not
macOS is that there might be a difference in the version of librsvg.
The way Emacs handles SVG files on both is pretty much identical
afaik, so any difference is likely to be down to librsvg.
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55322
; Package
emacs
.
(Tue, 10 May 2022 01:44:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 55322 <at> debbugs.gnu.org (full text, mbox):
> On May 9, 2022, at 5:42 PM, Alan Third <alan <at> idiocy.org> wrote:
>
> Try messing with the base-uri, perhaps try setting it to the
> directory, or to foo.svg or something.
I had tried using a directory as :base-uri but that didn't help.
> My first guess would be that if it's working on GNU/Linux but not
> macOS is that there might be a difference in the version of librsvg.
> The way Emacs handles SVG files on both is pretty much identical
> afaik, so any difference is likely to be down to librsvg.
Hmmm, so I got the latest version from https://emacsformacosx.com/
and that doesn't seem to support svg at all (any more?). I'll have
to look into it more or learn to build my own on mac.
Thanks
Howard
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55322
; Package
emacs
.
(Tue, 10 May 2022 17:18:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 55322 <at> debbugs.gnu.org (full text, mbox):
On Mon, May 09, 2022 at 09:43:45PM -0400, Howard Melman wrote:
>
> > On May 9, 2022, at 5:42 PM, Alan Third <alan <at> idiocy.org> wrote:
> >
> > Try messing with the base-uri, perhaps try setting it to the
> > directory, or to foo.svg or something.
>
> I had tried using a directory as :base-uri but that didn't help.
Hmm, I tried looking at the librsvg source to see if I could work out
whether there's anything funny going on, but it's in rust and I don't
understand it, so that didn't help at all. I'm pretty much stumped. If
I get a chance I'll see if I can dig the Mac out and see if I can
reproduce it.
> > My first guess would be that if it's working on GNU/Linux but not
> > macOS is that there might be a difference in the version of librsvg.
> > The way Emacs handles SVG files on both is pretty much identical
> > afaik, so any difference is likely to be down to librsvg.
>
> Hmmm, so I got the latest version from https://emacsformacosx.com/
> and that doesn't seem to support svg at all (any more?). I'll have
> to look into it more or learn to build my own on mac.
Maybe try Jim's builds:
https://github.com/jimeh/emacs-builds
I know SVG was working on them recently.
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55322
; Package
emacs
.
(Tue, 10 May 2022 18:02:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 55322 <at> debbugs.gnu.org (full text, mbox):
On Tue, May 10, 2022 at 06:17:03PM +0100, Alan Third wrote:
> On Mon, May 09, 2022 at 09:43:45PM -0400, Howard Melman wrote:
> >
> > > On May 9, 2022, at 5:42 PM, Alan Third <alan <at> idiocy.org> wrote:
> > >
> > > Try messing with the base-uri, perhaps try setting it to the
> > > directory, or to foo.svg or something.
> >
> > I had tried using a directory as :base-uri but that didn't help.
>
> Hmm, I tried looking at the librsvg source to see if I could work out
> whether there's anything funny going on, but it's in rust and I don't
> understand it, so that didn't help at all. I'm pretty much stumped. If
> I get a chance I'll see if I can dig the Mac out and see if I can
> reproduce it.
I actually just did this while waiting for my dinner, and it works
fine here using an image I had lying around. I'm trying to upgrade my
librsvg to the latest version in case mine is too old, but it's taking
forever.
Can you please ensure that the image being referenced in the SVG is
actually there and that Emacs is able to open it directly?
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55322
; Package
emacs
.
(Wed, 11 May 2022 00:01:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 55322 <at> debbugs.gnu.org (full text, mbox):
On May 10, 2022, at 2:01 PM, Alan Third <alan <at> idiocy.org> wrote:
>
> On Tue, May 10, 2022 at 06:17:03PM +0100, Alan Third wrote:
>> On Mon, May 09, 2022 at 09:43:45PM -0400, Howard Melman wrote:
>>>
>>>> On May 9, 2022, at 5:42 PM, Alan Third <alan <at> idiocy.org> wrote:
>>>>
>>>> Try messing with the base-uri, perhaps try setting it to the
>>>> directory, or to foo.svg or something.
>>>
>>> I had tried using a directory as :base-uri but that didn't help.
>>
>> Hmm, I tried looking at the librsvg source to see if I could work out
>> whether there's anything funny going on, but it's in rust and I don't
>> understand it, so that didn't help at all. I'm pretty much stumped. If
>> I get a chance I'll see if I can dig the Mac out and see if I can
>> reproduce it.
>
> I actually just did this while waiting for my dinner, and it works
> fine here using an image I had lying around. I'm trying to upgrade my
> librsvg to the latest version in case mine is too old, but it's taking
> forever.
>
> Can you please ensure that the image being referenced in the SVG is
> actually there and that Emacs is able to open it directly?
At the time I absolutely verified this. OSM lets you click around the map
to drop a pin and so those tiles get redrawn with the underllying map and
the pin, just like in the result of a search. Clicking around showed these
same issues too, which is what convinced me the tile were there and
drawable. Also I opened the original tile and it rendered fine.
I can't quite reproduce this now. I installed a new version from emacsformac
and upgraded osm which does more checks. I can't quite verify that
the emacsformac build links in librsvg. I will try the other build you
mentioned, I was unaware of it.
Thanks.
Howard
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55322
; Package
emacs
.
(Wed, 11 May 2022 00:18:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 55322 <at> debbugs.gnu.org (full text, mbox):
On May 10, 2022, at 1:17 PM, Alan Third <alan <at> idiocy.org> wrote:
>
> Maybe try Jim's builds:
>
> https://github.com/jimeh/emacs-builds
>
> I know SVG was working on them recently.
It works fine with this build and the latest version of osm.
The relevant portion of the image is below, so it is clear
that the :base-uri is working and is the same as what
didn't previously work for me.
My best guess is that the version from emacsformac
I was using had an old librsvg linked.
Howard
7 8 (display (image :width 256 :height 256 :file "/Users/hmelman/.emacs.d/var/osm/default/17-39607-48480.png" :type png)) 8 9 (display (image :width 256 :height 256 :type svg :base-uri "/Users/hmelman/.emacs.d/var/osm/default/17-39608-48480.png" :data "<svg width='256' height='256' version='1.1'
xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink'>
<image xlink:href='17-39608-48480.png' height='256' width='256'/>
<g fill='#80f' stroke='#208' stroke-width='9' transform='translate(221 156) scale(0.09) translate(-256 -512)'>
<path d='M256 0C167.641 0 96 71.625 96 160c0 24.75 5.625 48.219 15.672
69.125C112.234 230.313 256 512 256 512l142.594-279.375
C409.719 210.844 416 186.156 416 160C416 71.625 344.375
0 256 0z M256 256c-53.016 0-96-43-96-96s42.984-96 96-96
c53 0 96 43 96 96S309 256 256 256z'/>
</g>
<g fill='#80f' stroke='#208' stroke-width='9' transform='translate(221 156) scale(0.09) translate(-256 -512)'>
<path d='M256 0C167.641 0 96 71.625 96 160c0 24.75 5.625 48.219 15.672
69.125C112.234 230.313 256 512 256 512l142.594-279.375
C409.719 210.844 416 186.156 416 160C416 71.625 344.375
0 256 0z M256 256c-53.016 0-96-43-96-96s42.984-96 96-96
c53 0 96 43 96 96S309 256 256 256z'/>
</g></svg>" :map (((poly . [221 156 201 116 221 106 241 116]) osm-home (help-echo "Home" pointer hand)) ((poly . [221 156 201 116 221 106 241 116]) osm-home (help-echo "Home" pointer hand)))
Reply sent
to
Alan Third <alan <at> idiocy.org>
:
You have taken responsibility.
(Wed, 11 May 2022 17:00:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Howard Melman <hmelman <at> gmail.com>
:
bug acknowledged by developer.
(Wed, 11 May 2022 17:00:03 GMT)
Full text and
rfc822 format available.
Message #34 received at 55322-done <at> debbugs.gnu.org (full text, mbox):
On Tue, May 10, 2022 at 08:17:32PM -0400, Howard Melman wrote:
> On May 10, 2022, at 1:17 PM, Alan Third <alan <at> idiocy.org> wrote:
> >
> > Maybe try Jim's builds:
> >
> > https://github.com/jimeh/emacs-builds
> >
> > I know SVG was working on them recently.
>
> It works fine with this build and the latest version of osm.
> The relevant portion of the image is below, so it is clear
> that the :base-uri is working and is the same as what
> didn't previously work for me.
>
> My best guess is that the version from emacsformac
> I was using had an old librsvg linked.
Thanks for working it through. I guess this means it's a problem with
the emacsformacosx.com builds.
--
Alan Third
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 09 Jun 2022 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 16 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.