GNU bug report logs - #47819
8.0.50; When :height/:width image attribute is specified, :scale factor is not applied

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47819 in the body.
You can then email your comments to 47819 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: David Ponce <da_vid <at> orange.fr>
To: bug-gnu-emacs <at> gnu.org
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

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

Message #8 received at 47819 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: David Ponce <da_vid <at> orange.fr>
Cc: 47819 <at> debbugs.gnu.org
Subject: Re: bug#47819: 8.0.50; When :height/:width image attribute is
 specified, :scale factor is not applied
Date: Fri, 16 Apr 2021 19:14:50 +0100

[Message part 1 (text/plain, inline)]

On Fri, Apr 16, 2021 at 08:16:20AM +0200, David Ponce wrote:
> 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.

Hmm, I'm not sure which is the more desirable behaviour, but fixing it
to match the documentation appears to be trivial. See attached.
-- 
Alan Third

[0001-Make-scale-affect-width-and-height-bug-47819.patch (text/plain, attachment)]

Message #11 received at 47819 <at> debbugs.gnu.org (full text, mbox):

From: David Ponce <da_vid <at> orange.fr>
To: Alan Third <alan <at> idiocy.org>, 47819 <at> debbugs.gnu.org
Subject: Re: bug#47819: 8.0.50; When :height/:width image attribute is
 specified, :scale factor is not applied
Date: Fri, 16 Apr 2021 20:50:58 +0200

On 16/04/2021 20:14, Alan Third wrote:
> On Fri, Apr 16, 2021 at 08:16:20AM +0200, David Ponce wrote:
>> 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.
> 
> Hmm, I'm not sure which is the more desirable behaviour, but fixing it
> to match the documentation appears to be trivial. See attached.
> 

Hi Alan,

Your patch fixed the issue for me, and now the specified :scale factor
is applied when the :height/:width attributes are specified.

IMHO, this is the right fix to be consistent with the
documentation. At least because create-image apply a default scale
factor, maybe for better rendering on high resolution
screens. For ex., a default scale factor of 1.2 is applied on my
laptop (1920x1080). Scaling could also make sense when height/width
are specified in 'em'?

Thanks!

Message #14 received at 47819 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: David Ponce <da_vid <at> orange.fr>
Cc: 47819 <at> debbugs.gnu.org
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:23:55 +0100

On Fri, Apr 16, 2021 at 08:50:58PM +0200, David Ponce wrote:
> On 16/04/2021 20:14, Alan Third wrote:
> > On Fri, Apr 16, 2021 at 08:16:20AM +0200, David Ponce wrote:
> > > 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.
> > 
> > Hmm, I'm not sure which is the more desirable behaviour, but fixing it
> > to match the documentation appears to be trivial. See attached.
> > 
> 
> Hi Alan,
> 
> Your patch fixed the issue for me, and now the specified :scale factor
> is applied when the :height/:width attributes are specified.
> 
> IMHO, this is the right fix to be consistent with the
> documentation. At least because create-image apply a default scale
> factor, maybe for better rendering on high resolution
> screens. For ex., a default scale factor of 1.2 is applied on my
> laptop (1920x1080). Scaling could also make sense when height/width
> are specified in 'em'?

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.
-- 
Alan Third

Message #19 received at 47819-done <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: David Ponce <da_vid <at> orange.fr>, 47819-done <at> debbugs.gnu.org
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

Previous Next

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