GNU bug report logs - #77429
31.0.50; Image map and display slice on mode/header/tab line

Previous Next

Package: emacs;

Reported by: David Ponce <da_vid <at> orange.fr>

Date: Tue, 1 Apr 2025 13:09:02 UTC

Severity: normal

Found in version 31.0.50

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: David Ponce <da_vid <at> orange.fr>
To: 77429 <at> debbugs.gnu.org
Subject: bug#77429: 31.0.50; Image map and display slice on mode/header/tab line
Date: Tue, 1 Apr 2025 15:06:49 +0200
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.





This bug report was last modified 49 days ago.

Previous Next


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