GNU bug report logs - #51596
image-transform-resize has inconsistent semantics wrt scaling up/down

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 51596 in the body.
You can then email your comments to 51596 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: Stefan Kangas <stefan <at> marxist.se>
To: bug-gnu-emacs <at> gnu.org
Subject: image-transform-resize has inconsistent semantics wrt scaling up/down
Date: Wed, 3 Nov 2021 21:14:58 -0700

I find the semantics of `image-transform-resize' inconsistent.  That
also goes for `image-auto-resize' and the corresponding functions.

"Fit height" and "fit width" both scales an image up or down, but "fit
height and width" only scales an image down.  Is that intentional?

I would have expected that they all scale in the same way, i.e. they
should all either scale up or down, or scale down only, or scale up
only.

My preference is that they scale both up or down, no matter which kind
of fitting you ask for.  The below diff seems to achieve what I want.
However, I'm not sure if the semantics should be changed in this way,
as I don't know if the old semantics were intentional or not.


diff --git a/lisp/image-mode.el b/lisp/image-mode.el
index 4a326cdc69..97efd8254d 100644
--- a/lisp/image-mode.el
+++ b/lisp/image-mode.el
@@ -880,7 +880,7 @@ image-toggle-display-image
                                   :format (and filename data-p))
 		  (create-image file-or-data type data-p :scale 1
 				:max-width max-width
-				:max-height max-height
+                                :height max-height
                                 ;; Type hint.
                                 :format (and filename data-p))))

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 51596 <at> debbugs.gnu.org
Subject: Re: bug#51596: image-transform-resize has inconsistent semantics
 wrt scaling up/down
Date: Thu, 04 Nov 2021 18:50:54 +0100

Stefan Kangas <stefan <at> marxist.se> writes:

> "Fit height" and "fit width" both scales an image up or down, but "fit
> height and width" only scales an image down.  Is that intentional?

Yes, I think so?  The point of the latter is that too-big images are
pretty useless -- you want to scale them down so that you can actually
see them.  But it doesn't therefore follow that you want to scale tiny
icons up to fill the screen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 51596 <at> debbugs.gnu.org
Subject: Re: bug#51596: image-transform-resize has inconsistent semantics wrt
 scaling up/down
Date: Thu, 4 Nov 2021 11:52:16 -0700

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Stefan Kangas <stefan <at> marxist.se> writes:
>
>> "Fit height" and "fit width" both scales an image up or down, but "fit
>> height and width" only scales an image down.  Is that intentional?
>
> Yes, I think so?  The point of the latter is that too-big images are
> pretty useless -- you want to scale them down so that you can actually
> see them.  But it doesn't therefore follow that you want to scale tiny
> icons up to fill the screen.

Right, and that's a valid use case of course.  I still find the
interface inconsistent, as the naming scheme suggests that these three
options should behave similarly.

I made a quick review of other image viewers:

emacs                  gthumb          geeqie                eog
-----                  ------          ------                ---
fit height and width   Automatic       Zoom 1:1              Best fit
<missing>              Fit to window   Fit image to window   <missing>
fit to width           Fit to width    <missing>             <missing>
fit to height          Fit to height   <missing>             <missing>

How about renaming "fit height and width" to something that suggests
that it behaves differently from "fit to width" and "fit to height", and
then adding a new option "fit to window" that scales up or down as
needed?

Perhaps we could even have a "smart" option that only scales images up
larger than some height and width, and otherwise leaves them in their
original size.  That's probably the one I would like to use, now that I
think about it.  (I usually prefer to scale images up, but as you point
out it's pretty useless to scale small icons to fit the window.)

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

From: Juri Linkov <juri <at> linkov.net>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 51596 <at> debbugs.gnu.org
Subject: Re: bug#51596: image-transform-resize has inconsistent semantics
 wrt scaling up/down
Date: Thu, 04 Nov 2021 21:16:07 +0200

> I made a quick review of other image viewers:
>
> emacs                  gthumb          geeqie                eog
> -----                  ------          ------                ---
> fit height and width   Automatic       Zoom 1:1              Best fit
> <missing>              Fit to window   Fit image to window   <missing>

What is “Fit to window”?  Does it distort the image
by changing its height/width ratio?

> fit to width           Fit to width    <missing>             <missing>
> fit to height          Fit to height   <missing>             <missing>
>
> How about renaming "fit height and width" to something that suggests
> that it behaves differently from "fit to width" and "fit to height", and
> then adding a new option "fit to window" that scales up or down as
> needed?

Its menu item already displays a hint “Best Fit”:

	["Fit Image to Window (Best Fit)" image-transform-fit-both
	 :help "Resize image to match the window height and width"]

> Perhaps we could even have a "smart" option that only scales images up
> larger than some height and width, and otherwise leaves them in their
> original size.  That's probably the one I would like to use, now that I
> think about it.  (I usually prefer to scale images up, but as you point
> out it's pretty useless to scale small icons to fit the window.)

Maybe a new user option (disabled by default) could scale up
like ImageMagick's '-resize' does.

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Juri Linkov <juri <at> linkov.net>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 51596 <at> debbugs.gnu.org
Subject: Re: bug#51596: image-transform-resize has inconsistent semantics wrt
 scaling up/down
Date: Thu, 4 Nov 2021 12:41:11 -0700

Juri Linkov <juri <at> linkov.net> writes:

>> I made a quick review of other image viewers:
>>
>> emacs                  gthumb          geeqie                eog
>> -----                  ------          ------                ---
>> fit height and width   Automatic       Zoom 1:1              Best fit
>> <missing>              Fit to window   Fit image to window   <missing>
>
> What is “Fit to window”?  Does it distort the image
> by changing its height/width ratio?

No, it preserves the aspect ratio.

>> Perhaps we could even have a "smart" option that only scales images up
>> larger than some height and width, and otherwise leaves them in their
>> original size.  That's probably the one I would like to use, now that I
>> think about it.  (I usually prefer to scale images up, but as you point
>> out it's pretty useless to scale small icons to fit the window.)
>
> Maybe a new user option (disabled by default) could scale up
> like ImageMagick's '-resize' does.

What does that option do?  (And yes, I imagine the above "smart"
resizing idea to be both optional and separate from the standard
options.)

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

From: Juri Linkov <juri <at> linkov.net>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 51596 <at> debbugs.gnu.org
Subject: Re: bug#51596: image-transform-resize has inconsistent semantics
 wrt scaling up/down
Date: Thu, 04 Nov 2021 21:49:55 +0200

> Juri Linkov <juri <at> linkov.net> writes:
>
>>> I made a quick review of other image viewers:
>>>
>>> emacs                  gthumb          geeqie                eog
>>> -----                  ------          ------                ---
>>> fit height and width   Automatic       Zoom 1:1              Best fit
>>> <missing>              Fit to window   Fit image to window   <missing>
>>
>> What is “Fit to window”?  Does it distort the image
>> by changing its height/width ratio?
>
> No, it preserves the aspect ratio.

What is the difference between “Automatic” and “Fit to window”?

>>> Perhaps we could even have a "smart" option that only scales images up
>>> larger than some height and width, and otherwise leaves them in their
>>> original size.  That's probably the one I would like to use, now that I
>>> think about it.  (I usually prefer to scale images up, but as you point
>>> out it's pretty useless to scale small icons to fit the window.)
>>
>> Maybe a new user option (disabled by default) could scale up
>> like ImageMagick's '-resize' does.
>
> What does that option do?  (And yes, I imagine the above "smart"
> resizing idea to be both optional and separate from the standard
> options.)

It scales up, unless a special character > is used at the end.

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Juri Linkov <juri <at> linkov.net>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 51596 <at> debbugs.gnu.org
Subject: Re: bug#51596: image-transform-resize has inconsistent semantics wrt
 scaling up/down
Date: Thu, 4 Nov 2021 13:19:40 -0700

Juri Linkov <juri <at> linkov.net> writes:

>>>> I made a quick review of other image viewers:
>>>>
>>>> emacs                  gthumb          geeqie                eog
>>>> -----                  ------          ------                ---
>>>> fit height and width   Automatic       Zoom 1:1              Best fit
>>>> <missing>              Fit to window   Fit image to window   <missing>
>>>
>>> What is “Fit to window”?  Does it distort the image
>>> by changing its height/width ratio?
>>
>> No, it preserves the aspect ratio.
>
> What is the difference between “Automatic” and “Fit to window”?

In gthumb, "Automatic" is like our "fit height and width" in that it
only scales down as needed, while "Fit to window" scales both up and
down.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 51596 <at> debbugs.gnu.org
Subject: Re: bug#51596: image-transform-resize has inconsistent semantics
 wrt scaling up/down
Date: Thu, 04 Nov 2021 23:52:40 +0100

Stefan Kangas <stefan <at> marxist.se> writes:

> Right, and that's a valid use case of course.  I still find the
> interface inconsistent, as the naming scheme suggests that these three
> options should behave similarly.

Yes.  I think that, basically, the fit to height/width commands are
pretty useless -- nobody wants that, because it'll inevitably make some
images impossible to view.

The two cases that make sense are "scale down so I can see the images"
and "both scale down and scale up, because I want to see as much detail
as possible".

> Perhaps we could even have a "smart" option that only scales images up
> larger than some height and width, and otherwise leaves them in their
> original size.  That's probably the one I would like to use, now that I
> think about it.  (I usually prefer to scale images up, but as you point
> out it's pretty useless to scale small icons to fit the window.)

Sure, or a "don't scale up more than 200%", perhaps.  That's less
finicky, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 51596 <at> debbugs.gnu.org
Subject: Re: bug#51596: image-transform-resize has inconsistent semantics wrt
 scaling up/down
Date: Thu, 4 Nov 2021 21:07:33 -0700

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

tags 51596 + patch
thanks

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Stefan Kangas <stefan <at> marxist.se> writes:
>
>> Right, and that's a valid use case of course.  I still find the
>> interface inconsistent, as the naming scheme suggests that these three
>> options should behave similarly.

I've attached a patch below which implements the behavior I propose.

> Yes.  I think that, basically, the fit to height/width commands are
> pretty useless -- nobody wants that, because it'll inevitably make some
> images impossible to view.
>
> The two cases that make sense are "scale down so I can see the images"
> and "both scale down and scale up, because I want to see as much detail
> as possible".

That's true, now that you mention it.  The first patch below therefore
obsoletes the old commands, mostly to free up the "s w" binding which
gives the new, and strictly better, behavior.

We could also leave them unobsoleted and still take over the key.  It
won't hurt anyone because, as you point out, the current command is only
different in the cases where its worse.

> Sure, or a "don't scale up more than 200%", perhaps.  That's less
> finicky, I think.

Yes, that's probably better.  For this part, see my second patch below,
which builds on the first one.

[0001-New-command-image-transform-fit-to-window.patch (text/x-diff, attachment)]

[0002-New-user-option-image-auto-resize-max-scale-percent.patch (text/x-diff, attachment)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 51596 <at> debbugs.gnu.org
Subject: Re: bug#51596: image-transform-resize has inconsistent semantics
 wrt scaling up/down
Date: Fri, 05 Nov 2021 14:22:29 +0100

Stefan Kangas <stefan <at> marxist.se> writes:

> That's true, now that you mention it.  The first patch below therefore
> obsoletes the old commands, mostly to free up the "s w" binding which
> gives the new, and strictly better, behavior.

Both patches make sense to me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Stefan Kangas <stefan <at> marxist.se>, 51596 <at> debbugs.gnu.org
Subject: Re: bug#51596: image-transform-resize has inconsistent semantics
 wrt scaling up/down
Date: Sat, 06 Nov 2021 20:49:18 +0200

>> That's true, now that you mention it.  The first patch below therefore
>> obsoletes the old commands, mostly to free up the "s w" binding which
>> gives the new, and strictly better, behavior.
>
> Both patches make sense to me.

➕1️⃣

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Juri Linkov <juri <at> linkov.net>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 51596 <at> debbugs.gnu.org
Subject: Re: bug#51596: image-transform-resize has inconsistent semantics wrt
 scaling up/down
Date: Sat, 6 Nov 2021 12:49:55 -0700

close 51596 29.1
thanks

Juri Linkov <juri <at> linkov.net> writes:

>>> That's true, now that you mention it.  The first patch below therefore
>>> obsoletes the old commands, mostly to free up the "s w" binding which
>>> gives the new, and strictly better, behavior.
>>
>> Both patches make sense to me.
>
> ➕1️⃣

💯

Pushed to master as commit fd141116f6 and 569d7f6a73.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: 51596 <at> debbugs.gnu.org
Subject: Re: master fd14111 1/2: New command image-transform-fit-to-window
Date: Sat, 6 Nov 2021 13:06:26 -0700

stefankangas <at> gmail.com (Stefan Kangas) writes:

> branch: master
> commit fd141116f67313c0d9787936cbaa4f12cfaffb9d
> Author: Stefan Kangas <stefan <at> marxist.se>
> Commit: Stefan Kangas <stefan <at> marxist.se>
>
>     New command image-transform-fit-to-window
>
>     * lisp/image-mode.el (image-auto-resize, image-transform-resize):
>     Add new value 'fit-window', meaning to scale the image up or down
>     to fit the window.  (Bug#)
>     (image-transform-fit-to-window): New command.
>     (image-transform-fit-to-height, image-transform-fit-to-width):
>     Make obsolete in favor of above new command.
>     (image-mode-map): Bind "s w" to 'image-transform-fit-to-window'.
>     Move binding for obsolete command 'image-transform-fit-to-width'
>     to "s i".
>     (image-mode-map): Add menu entry for
>     'image-transform-fit-to-window'.  Remove menu entries for above
>     obsolete commands.
>     * doc/emacs/files.texi (Image Mode): Update documentation.
>     (image-transform-fit-both): Doc fix.

Ugh, I missed including the bug number.

I'm sending the full commit message with the full SHA here in case
anyone tries searching for it later.

Previous Next

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