GNU bug report logs -
#37578
26.3; image-mode does not display the bottom edge of a tall image
Previous Next
Reported by: ynyaaa <at> gmail.com
Date: Wed, 2 Oct 2019 09:02:01 UTC
Severity: normal
Found in version 26.3
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 37578 in the body.
You can then email your comments to 37578 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37578
; Package
emacs
.
(Wed, 02 Oct 2019 09:02:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
ynyaaa <at> gmail.com
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 02 Oct 2019 09:02:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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))
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37578
; Package
emacs
.
(Wed, 02 Oct 2019 20:06:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 37578 <at> debbugs.gnu.org (full text, mbox):
On Wed, Oct 02, 2019 at 06:00:38PM +0900, ynyaaa <at> 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
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Sat, 05 Oct 2019 09:04:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
ynyaaa <at> gmail.com
:
bug acknowledged by developer.
(Sat, 05 Oct 2019 09:04:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 37578-done <at> debbugs.gnu.org (full text, mbox):
> From: ynyaaa <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37578
; Package
emacs
.
(Wed, 23 Oct 2019 16:09:01 GMT)
Full text and
rfc822 format available.
Message #16 received at 37578 <at> debbugs.gnu.org (full text, mbox):
help-debbugs <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37578
; Package
emacs
.
(Wed, 23 Oct 2019 17:59:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 37578 <at> debbugs.gnu.org (full text, mbox):
> From: Tassilo Horn <tsdh <at> gnu.org>
> Cc: ynyaaa <at> gmail.com, 37578 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37578
; Package
emacs
.
(Wed, 23 Oct 2019 18:50:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 37578 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I have already adapted my package in a branch. And I think the required changes are straightforward. I suppose the same holds for doc-view.
Andreas
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37578
; Package
emacs
.
(Wed, 23 Oct 2019 18:58:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 37578 <at> debbugs.gnu.org (full text, mbox):
On October 23, 2019 8:49:17 PM Andreas Politz <politza <at> hochschule-trier.de>
wrote:
> I have already adapted my package in a branch. And I think the required
> changes are straightforward. I suppose the same holds for doc-view.
Ok, great. I'll adapt doc-view.el ASAP and then close this issue. Thanks
for your report.
Bye,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37578
; Package
emacs
.
(Wed, 23 Oct 2019 19:03:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 37578 <at> debbugs.gnu.org (full text, mbox):
> From: Tassilo Horn <tsdh <at> gnu.org>
> CC: <37578 <at> debbugs.gnu.org>, <37874 <at> debbugs.gnu.org>
> Date: Wed, 23 Oct 2019 20:56:48 +0200
>
> On October 23, 2019 8:49:17 PM Andreas Politz <politza <at> hochschule-trier.de>
> wrote:
>
> > I have already adapted my package in a branch. And I think the required
> > changes are straightforward. I suppose the same holds for doc-view.
>
> Ok, great. I'll adapt doc-view.el ASAP and then close this issue. Thanks
> for your report.
Thanks, and sorry again for not being more vigilant.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37578
; Package
emacs
.
(Fri, 25 Oct 2019 20:24:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 37578 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> > I have already adapted my package in a branch. And I think the
>> > required changes are straightforward. I suppose the same holds for
>> > doc-view.
>>
>> Ok, great. I'll adapt doc-view.el ASAP and then close this
>> issue. Thanks for your report.
I've fixed doc-view just now (bug#37874) with commit a0f7ea5999.
> Thanks, and sorry again for not being more vigilant.
You're welcome,
Tassilo
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 23 Nov 2019 12:24:13 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 267 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.