bug#55322: 28.1; :base-uri not working for svg images on mac

[Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Howard Melman <hmelman@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.