bug#37578: 26.3; image-mode does not display the bottom edge of a tall image

bug#37578: 26.3; image-mode does not display the bottom edge of a tall image

[ynyaaa]

When viewing a tall image with image-mode, 
typing M-> shows bottom side of the image.
But the lowest edge is not displayed.

Evaluate the form below and type M->,
the bottom curve (semicircle) is partially hidden.

(let ((svg-data "\
<svg width=\"100\" height=\"1500\"
     xmlns=\"http://www.w3.org/2000/svg\">
  <rect fill=\"blue\" rx=\"50\" ry=\"50\" width=\"100\" height=\"1500\"/>
</svg>
"))
  (switch-to-buffer (generate-new-buffer "tmp"))
  (insert svg-data)
  (image-mode))



In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
 of 2019-08-29 built on CIRROCUMULUS
Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd
Windowing system distributor 'Microsoft Corp.', version 6.3.9600
Recent messages:

Configured using:
 'configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS THREADS LCMS2

Important settings:
  value of $LANG: JPN
  locale-coding-system: cp932

Major mode: Image[svg]

Minor modes in effect:
  tooltip-mode: t
  global-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 seq byte-opt gv
bytecomp byte-compile cconv dired dired-loaddefs format-spec rfc822 mml
mml-sec password-cache epa derived epg epg-config gnus-util rmail
rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils cl-extra thingatpt help-fns radix-tree
help-mode cl-loaddefs cl-lib image-mode easymenu elec-pair time-date
mule-util japan-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame 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 minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads w32notify w32 lcms2 multi-tty make-network-process
emacs)

Memory information:
((conses 16 103477 11081)
 (symbols 48 20530 1)
 (miscs 40 45 179)
 (strings 32 30942 1391)
 (string-bytes 1 796453)
 (vectors 16 15797)
 (vector-slots 8 581334 12678)
 (floats 8 61 125)
 (intervals 56 242 0)
 (buffers 992 13))

bug#37578: 26.3; image-mode does not display the bottom edge of a tall image

[Alan Third]

On Wed, Oct 02, 2019 at 06:00:38PM +0900, ynyaaa@gmail.com wrote:
> 
> When viewing a tall image with image-mode, 
> typing M-> shows bottom side of the image.
> But the lowest edge is not displayed.
> 
> Evaluate the form below and type M->,
> the bottom curve (semicircle) is partially hidden.
> 
> (let ((svg-data "\
> <svg width=\"100\" height=\"1500\"
>      xmlns=\"http://www.w3.org/2000/svg\">
>   <rect fill=\"blue\" rx=\"50\" ry=\"50\" width=\"100\" height=\"1500\"/>
> </svg>
> "))
>   (switch-to-buffer (generate-new-buffer "tmp"))
>   (insert svg-data)
>   (image-mode))

Confirmed in master. Oddly I can scroll to the bottom of the image
using the mousewheel, but not with the keyboard.

-- 
Alan Third

bug#37578: 26.3; image-mode does not display the bottom edge of a tall image

[Eli Zaretskii]

> From: ynyaaa@gmail.com
> Date: Wed, 02 Oct 2019 18:00:38 +0900
> 
> When viewing a tall image with image-mode, 
> typing M-> shows bottom side of the image.
> But the lowest edge is not displayed.

image-mode.el was scrolling images vertically in units of canonical
character height, so it couldn't handle the last portion of an image
smaller than the height of one character.

This is now fixed on the master branch.

Thanks.

bug#37578: closed (Re: bug#37578: 26.3; image-mode does not display the bottom edge of a tall image)

[Tassilo Horn]

help-debbugs@gnu.org (GNU bug Tracking System) writes:

Hi Eli,

>> When viewing a tall image with image-mode, 
>> typing M-> shows bottom side of the image.
>> But the lowest edge is not displayed.
>
> image-mode.el was scrolling images vertically in units of canonical
> character height, so it couldn't handle the last portion of an image
> smaller than the height of one character.
>
> This is now fixed on the master branch.

Your change 9c66b09950cf2db50eb6d818656a268ef750bfe6 broke doc-view.el
and the pdf-tools package whose author already filed bug#37874 for the
issue.

Could you have a look?  If the image functions stay returning pixel
values that's ok but Andreas and I will need to adapt pdf-tools and
doc-view.el accordingly.

Bye,
Tassilo

bug#37874: bug#37578: closed (Re: bug#37578: 26.3; image-mode does not display the bottom edge of a tall image)

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: ynyaaa@gmail.com,  37578@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> Date: Wed, 23 Oct 2019 18:07:53 +0200
> 
> > image-mode.el was scrolling images vertically in units of canonical
> > character height, so it couldn't handle the last portion of an image
> > smaller than the height of one character.
> >
> > This is now fixed on the master branch.
> 
> Your change 9c66b09950cf2db50eb6d818656a268ef750bfe6 broke doc-view.el
> and the pdf-tools package whose author already filed bug#37874 for the
> issue.
> 
> Could you have a look?  If the image functions stay returning pixel
> values that's ok but Andreas and I will need to adapt pdf-tools and
> doc-view.el accordingly.

Sorry, I didn't think some other package will use that function, it
looked like an internal subroutine.  I should have checked.

To answer your question: I see no reason to go back to character units
in this function.  We could either adapt the other packages to the
change, or add a new function that will work like the previous
image-next-line.  What would you prefer?  If the only problem is with
comparing against the value returned by window-vscroll, then perhaps
the former is easier and simpler?

Thanks.