GNU bug report logs - #71666
30.0.50; [PATCH] Fix zooming images with SHR

Previous Next

Package: emacs;

Reported by: Jim Porter <jporterbugs <at> gmail.com>

Date: Thu, 20 Jun 2024 04:48:02 UTC

Severity: normal

Tags: patch

Merged with 63344

Found in versions 29.0.90, 30.0.50

Done: Jim Porter <jporterbugs <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 71666 <at> debbugs.gnu.org
Subject: bug#71666: 30.0.50; [PATCH] Fix zooming images with SHR
Date: Sun, 23 Jun 2024 07:44:09 +0300
> Date: Sat, 22 Jun 2024 13:21:53 -0700
> Cc: 71666 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> On 6/22/2024 2:11 AM, Eli Zaretskii wrote:
> > I tried the recipe and the patch.  While the patches shr behaves
> > better than the unpatched, I don't see the image being zoomed, it
> > stays at its original size.  Do I need some optional library or
> > external program for the zoom to happen?
> 
> Ah right, that would have been helpful for me to mention in the original 
> message: by default, SHR scales down images that are more than 70% of 
> the width (or height) of the window. So if you narrow your window to 40 
> columns or so and reload the page in EWW, the larger images should be 
> scaled down. Then putting point on one and pressing "z" should scale it 
> up to the original size. Pressing "z" again should scale the image back 
> down.

OK, then feel free to install, and thanks.

> As an aside, there are actually *three* states for image scaling in SHR: 
> default, original, and full, and 'shr-zoom-image' cycles through them in 
> that order. As far as I can tell from the code, "default" and "full" are 
> the same though. I haven't figured out whether that's a bug (and if so, 
> what the bug is), or whether I'm just misunderstanding something. I'll 
> try to fix that later (if only by adding documentation), once I know 
> what's going on.

I must say this kind of dwim-ish operation that looks like no-op in
too many "normal" cases looks very strange to me.  How does it make
sense to have features that only appear to do something in rare cases?
Doesn't that cause user bewilderment (like I was surprised above), and
cause users to think we have a bug?  Should we perhaps adjust the
heuristics and its parameters to make this not no-op in more cases?
Or at least show a message in echo area explaining why the image was
not zoomed-in when we decide not to?  For example, in the case above,
why would it not make sense to enlarge the image when the user presses
'z' even if it was not scaled down initially?  Doesn't principle of
least surprise count anymore?




This bug report was last modified 319 days ago.

Previous Next


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