Subject: bug#77429: closed (Re: bug#77429: 31.0.50; Image map and display slice on mode/header/tab line)

From: [email-masked] (GNU bug Tracking System)
Date: Wed, 02 Apr 2025 14:03:04 +0000

Your bug report

#77429: 31.0.50; Image map and display slice on mode/header/tab line

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
77429: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=77429
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#77429: 31.0.50; Image map and display slice on mode/header/tab line
From: Eli Zaretskii <[email-masked]>
To: David Ponce <[email-masked]>
Cc: [email-masked]
Date: Wed, 02 Apr 2025 17:01:54 +0300
List-Id: <debbugs-submit.debbugs.gnu.org>

> Date: Wed, 2 Apr 2025 15:50:01 +0200
> Cc: [email-masked]
> From: David Ponce <[email-masked]>
> 
> >> But on the sliced image which is on the left side on the header line,
> >> showing a green and blue rectangle, a click on the green rectangle
> >> displays "Red" instead of "Green" and click on the blue rectangle
> >> displays "Green" instead of "Blue".  This is the issue.
> >>
> >> Hope I am clear enough.
> > 
> > Yes, thanks.  Should be fixed now on the master branch.
> 
> Yes, I confirm the bug is now fixed.
>  From my side, you can close this report.

Done.

Subject: 31.0.50; Image map and display slice on mode/header/tab line
From: David Ponce <[email-masked]>
To: [email-masked]
Date: Tue, 1 Apr 2025 15:06:49 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

Hello,

I discovered an inconsistency in the interpretation of image map
coordinates when the sliced image is displayed, depending on whether it's
displayed in a buffer or in a mode, header or tab line.

When the sliced image is displayed in a buffer, the image coordinates
remain relative to the unclipped image, which looks correct to me.  But,
it is no longer the case when the image is displayed in a mode, header
or tab line: then the image map coordinates become relative to the
visible portion of the image, which renders the map unusable.  The
following code illustrates the problem:

(require 'svg)
(let* ((w 304)
        (h (frame-char-height))
        (svg (svg-create w h)))
   (svg-rectangle svg 0   0 100 h :fill "red")
   (svg-rectangle svg 102 0 100 h :fill "green")
   (svg-rectangle svg 204 0 100 h :fill "blue")
   (let* ((img (svg-image svg :scale 1
                          :map
                          `(
                            ((rect . ((0   . 0) . (100 . ,h)))
                             r (help-echo "RED"   pointer hand))
                            ((rect . ((102 . 0) . (202 . ,h)))
                             g (help-echo "GREEN" pointer hand))
                            ((rect . ((204 . 0) . (304 . ,h)))
                             b (help-echo "BLUE"  pointer hand))
                            )))
          (full (propertize " " 'display img))
          (cut  (propertize " " 'display `((slice 102 0 202 1.0) ,img)))
          (both (concat cut " " full)))
     (setq header-line-format both)
     (insert both "\n")))

I'm reporting this inconsistency, at least to find out if it's a real
bug or a limitation that needs to be addressed by the programmer.

Thanks

In GNU Emacs 31.0.50 (build 5, x86_64-pc-linux-gnu, GTK+ Version
  3.24.43, cairo version 1.18.0) of 2025-03-31
Repository revision: 6f311883d246df87fa3ed9c24dbb39078e3fd69f
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12014000
System Description: Fedora Linux 40 (KDE Plasma)

Configured using:
  'configure --with-native-compilation=no'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINERAMA XINPUT2 XPM
XRANDR GTK3 ZLIB

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

Major mode: Lisp Interaction

Minor modes in effect:
   tooltip-mode: t
   global-eldoc-mode: t
   eldoc-mode: t
   show-paren-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
   minibuffer-regexp-mode: t
   line-number-mode: t
   indent-tabs-mode: t
   transient-mark-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t

Load-path shadows:
None found.