emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#47819: closed (8.0.50; When :height/:width image attribute is specif


From: GNU bug Tracking System
Subject: bug#47819: closed (8.0.50; When :height/:width image attribute is specified, :scale factor is not applied)
Date: Sat, 17 Apr 2021 08:43:02 +0000

Your message dated Sat, 17 Apr 2021 09:42:18 +0100
with message-id <YHqfajExu5S/90UA@breton.holly.idiocy.org>
and subject line Re: bug#47819: 8.0.50; When :height/:width image attribute is 
specified, :scale factor is not applied
has caused the debbugs.gnu.org bug report #47819,
regarding 8.0.50; When :height/:width image attribute is specified, :scale 
factor is not applied
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
47819: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=47819
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: 8.0.50; When :height/:width image attribute is specified, :scale factor is not applied Date: Fri, 16 Apr 2021 08:16:20 +0200 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1
Hello,

For the image :scale attribute the Elisp reference manual say that:

     If both ‘:scale’ and ‘:height’/‘:width’ are
     specified, the height/width will be adjusted by the specified
     scaling factor.

It seems, however, that this is not true, when the :height or :width
or both attributes of an image are specified, the :scale factor is not
applied.  For ex., evaluating the below code in the *scratch* buffer
should produce images with same size, but in the 2nd case the scale
factor is not applied:

(progn
  (insert-image
   (find-image
    '((:file "/usr/share/icons/oxygen/base/22x22/places/folder.png"
             :type png
             :scale 2
             ))))
  (insert-image
   (find-image
    '((:file "/usr/share/icons/oxygen/base/22x22/places/folder.png"
             :type png
             :scale 2
             :height 22
             :width 22
             ))))
  )

So, either the manual is wrong, or (better IMO) the code should be
fixed.

Thanks & Regards,
David Ponce


In GNU Emacs 28.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version 3.24.28, cairo 
version 1.16.0)
 of 2021-04-15 built on kilauea
Repository revision: c2372096433e6a7ab173e5f1993f0c65b85f353e
Repository branch: master
Windowing system distributor 'Fedora Project', version 11.0.12011000
System Description: Fedora 33 (KDE Plasma)

Configured using:
 'configure --prefix=/home/dponce --with-cairo
 PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XDBE XIM XPM 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
  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
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 50691 7522)
 (symbols 48 6501 1)
 (strings 32 18168 1362)
 (string-bytes 1 604792)
 (vectors 16 12723)
 (vector-slots 8 171820 12342)
 (floats 8 23 45)
 (intervals 56 197 0)
 (buffers 992 10))



--- End Message ---
--- Begin Message --- Subject: Re: bug#47819: 8.0.50; When :height/:width image attribute is specified, :scale factor is not applied Date: Sat, 17 Apr 2021 09:42:18 +0100
On Sat, Apr 17, 2021 at 09:23:55AM +0100, Alan Third wrote:
> 
> I don't know why you would want to use scale with em dimensions, since
> you can just set the em dimensions directly.
> 
> For example ":scale 2 :height '(1 . em)" is exactly the same as
> ":scale 1 :height '(2 . em)", so why bother?
> 
> Plus if you specify something to be 1em in height, then create-image
> applies its magic scale factor, you end up with something that is not
> 1em in height.
> 
> So yeah, I'm not convinced that this is behaviour we want.

OK, I'm still convinced this isn't really the behaviour we want, but I
did some further investigation and realised this is a bug introduced
by me recently. I thought it had worked this way for a long time.

I'll just push the change up to fix it.
-- 
Alan Third


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]