Map not displaying properly

[hmelman]

I'm seeing stuff like this using osm. If I click in various places on the map it moves around and sometimes two of these appear. Sometimes they display as blank grey square. I thought it might be related to global-hl-line-mode but turning that off had no effect.

[minad]

I have never seen this. Do the squares update if after some time you press g (revert-buffer)? The blue question mark indicates that we've got a broken image (but the question mark is mac specific). Maybe your curl version is broken. You should also try to delete all existing images from your image cache in ~/.config/emacs/var/osm/.

[hmelman]

osm used to work, though I haven't tried it in several weeks. reverting doesn't change anything. If I scroll (using arrows) the box moves and the rest of the map is fine. If I click the box moves and what was underneath it displays fine. Sometimes if I click someplace several boxes display this way. Deleting the cache didn't change anything though now the box under the home location doesn't ever display nicely.

My curl is evidently what ships with mac:

hmelman@~$ curl --version
curl 7.64.1 (x86_64-apple-darwin20.0) libcurl/7.64.1 (SecureTransport) LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.41.0
Release-Date: 2019-03-27
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets

[minad]

Okay, I think I misunderstood the issue. The issue is that the bitmap below the pin symbol svg is not displayed correctly. I assume the problem is that your Emacs build is broken and doesn't support the svg bitmap background properly. Maybe you use an outdated version of Emacs 28? See the relevant code:

https://github.com/minad/osm/blob/17884f69eb9681db880865af73762686c8e83cc0/osm.el#L928-L938

[minad]

You could try to replace the (> emacs-major-version 27) with nil and see if the problem persists.

[hmelman]

Yes that seems to be it. Note it failed with both the Emacs 28 versions of the macport and the vanilla gnu emacs.

[minad]

Okay, I see. This is probably a Mac-related Emacs bug then or with your specific build (is it 28.1?). The :base-uri for the svg is maybe not interpreted correctly or ignored, such that the image is not found, which then results in the question mark image (which is the usual symbol if the file is not found). Maybe the :base-uri should be a directory instead? If I recall correctly, I had issues before with file path interpretation on Mac.

https://github.com/minad/osm/blob/17884f69eb9681db880865af73762686c8e83cc0/osm.el#L961

If you manage to reproduce this with a small svg independently of osm.el, the issue could be reported upstream. You can try the function svg-embed-base-uri-image.

[hmelman]

Ok, both are prebuilt Emacs 28.1. I don't know anything about svg.el and osm--draw-tile isn't exactly trivial, I have no idea how to produce a test case or report this.

[minad]

You can try to reproduce it with the svg.el API. In particular the function svg-embed-base-uri-image will use the same mechanism as I use in osm.el. But yes, it is not really trivial.

[hmelman]

This is what osm--draw-tile is returning:

(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))))

If I change the above line 961 to this I get grey boxes instead of question marks (does that mean it's not finding the question mark image so it's worse?).

(list 'image :width 256 :height 256 :type 'svg :base-uri (file-name-directory file) :data svg-text :map areas)

Is there a way for me to see the svg text of osm buffer?

And FYI, it seems vanilla emacs on mac uses librsvg and the macport uses webkit to render svg instead. I've tried on both (on an intel mac) and they both fail similarly.

[minad]

No idea about the gray images. Please ask the respective maintainers of those distributions. I don't have access to a Mac. This is also not an osm.el bug strictly speaking since I just use the Emacs image display API and everything works fine on X11 Linux. You can retrieve the SVG text by adding some print statements or by inspecting the (buffer-string) and the attached display properties.

[hmelman]

I take it back a little, on vanilla emacs -Q, after loading just osm.elc and searching for "New York" I see maps like this. If I click around it seems some area is displayed at a different magnification. This happens on vanilla emacs if I use the embedded path images or not (changing the check of > 27 to > 28). On macport emacs the non-embedded path images work just fine.

[minad]

Interesting. I see none of those issues. I suggest you move over to a better and free operating. :wink:

Citing from https://www.gnu.org/software/emacs/download.html :laughing:

To improve the use of proprietary systems is a misguided goal. Our aim, rather, is to eliminate them. We include support for some proprietary systems in GNU Emacs in the hope that running Emacs on them will give users a taste of freedom and thus lead them to free themselves.

[hmelman]

Please ask the respective maintainers of those distributions.

My problem is I didn't know what to ask them. The buffer-string hint helped. Opened as Emacs bug#55322

I believe I learned that "xlink:href" in image tags is deprecated in favor of just "href", but you probably know better than me and it didn't help in this case.

Also it would be nice if the newly required compat library was only required for Emacs before 28. That way the recipe I give to emacs maintainers wouldn't have to include loading the (in this case unneeded) compat library too.

[minad]

I believe I learned that "xlink:href" in image tags is deprecated in favor of just "href", but you probably know better than me and it didn't help in this case.

I don't know if xlink:href is still supposed to be used. But svg-embed-base-uri-image from svg.el does just the same, so it should be okay.

Also it would be nice if the newly required compat library was only required for Emacs before 28. That way the recipe I give to emacs maintainers wouldn't have to include loading the (in this case unneeded) compat library too.

It shouldn't matter if compat.el is always required. compat.el seems like a solid effort and I hope it becomes more widely adopted. It can replace some other *-compat libraries which exist already within Emacs.

I think in order to reproduce this properly one should create a minimal recipe not based on osm.el, e.g., a small snippet which inserts an svg with :base-uri. It is likely that the Emacs maintainers expect such a more minimal recipe.

[hmelman]

I did the best I could.

[minad]

Yes, the string you posted is probably sufficient to check if svgs with :base-uris are supposed to work on the respective mac ports.

[hmelman]

It would be great if you could include checks for (featurep 'mac) and (featurep 'ns) in addition to (> emacs-major-version 27)in the choice to use :base-uri until this gets resolved.

[minad]

It would be great if you could include checks for (featurep 'mac) and (featurep 'ns) in addition to (> emacs-major-version 27)in the choice to use :base-uri until this gets resolved.

I can do that if it turns out that this feature is indeed not supported on Mac and that no support is planned. For that I need a confirmation on the bug tracker. Otherwise bugs will never get fixed.

(For example in my Corfu package, there was the question if we should add a workaround for flyspell, see https://github.com/minad/corfu/issues/163#issuecomment-1116257282. It turned out that autocomplete has a workaround since twelve years ago...)

[mituharu]

It seems that WebKit 2 does not allow us to embed local file images into an SVG image data (by default, at least). An immediate workaround for the Mac port is to compile it with librsvg.

[hmelman]

Thank you @mituharu

Is there a lisp level test on the macport to see if emacs is compiled with librsvg. (featurep 'svg) returns t for me on the railwaycat build which I think is correct but also I think isn't built with librsvg.

[mituharu]

(feacherp 'svg) = t does not mean the availability of SVG display; it means svg.el has been loaded. You should check (memq 'svg image-types) instead. Still it doesn't tell whether librsvg is used. You can find RSVG in system-configuration-features if librsvg is linked, but its documentation discourages us from using it for feature testing. Also, WebKit 1 (which is used on <= macOS 10.12 or 32-bit binaries) can embed local images successfully. I have installed some change to the "work" branch of the Mac port repository, so SVG via WebKit 2 can also embed local images: https://bitbucket.org/mituharu/emacs-mac/commits/ec519b7103dc9d27d0070c89fbce23f8bc0f8a0d

[hmelman]

Awesome, thanks very much.