GNU bug report logs -
#13887
24.3; doc-view will render blurry images when image-magick is available
Previous Next
Reported by: E Sabof <esabof <at> gmail.com>
Date: Wed, 6 Mar 2013 03:42:02 UTC
Severity: normal
Tags: moreinfo
Found in version 24.3
Done: Lars Ingebrigtsen <larsi <at> gnus.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 13887 in the body.
You can then email your comments to 13887 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#13887; Package
emacs.
(Wed, 06 Mar 2013 03:42:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
E Sabof <esabof <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Wed, 06 Mar 2013 03:42:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
It tries to up-scale the available bitmap - leading to a loss
of quality, instead of re-rendering the page from vector data.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Wed, 06 Mar 2013 08:07:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 13887 <at> debbugs.gnu.org (full text, mbox):
E Sabof <esabof <at> gmail.com> writes:
> It tries to up-scale the available bitmap - leading to a loss of
> quality, instead of re-rendering the page from vector data.
You mean, it up-scales when you hit +? That's a feature, because
up-scaling is much faster than reconverting. To make use of the
feature, you should set `doc-view-resolution' to some reasonably high
value. I use this
(setq doc-view-resolution 200)
and it works very well.
Bye,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Wed, 06 Mar 2013 12:15:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 13887 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I've tried it, indeed it works much better. Might it be possible to store
the the "native" size, and raise the resolution automatically when the zoom
exceeds it?
On a side note, might it be also possible to horizontally center the image?
There is a pretty straight-forward way to do it, used in the about-emacs
screen.
Evgeni
On Wed, Mar 6, 2013 at 8:05 AM, Tassilo Horn <tsdh <at> gnu.org> wrote:
> E Sabof <esabof <at> gmail.com> writes:
>
> > It tries to up-scale the available bitmap - leading to a loss of
> > quality, instead of re-rendering the page from vector data.
>
> You mean, it up-scales when you hit +? That's a feature, because
> up-scaling is much faster than reconverting. To make use of the
> feature, you should set `doc-view-resolution' to some reasonably high
> value. I use this
>
> (setq doc-view-resolution 200)
>
> and it works very well.
>
> Bye,
> Tassilo
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Wed, 06 Mar 2013 13:02:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 13887 <at> debbugs.gnu.org (full text, mbox):
E Sabof <esabof <at> gmail.com> writes:
> I've tried it, indeed it works much better. Might it be possible to
> store the the "native" size, and raise the resolution automatically
> when the zoom exceeds it?
Well, the resolution should be increased and the doc reconverted when
the up-scaled image becomes blurry. But how should emacs know when you
think it becomes blurry?
> On a side note, might it be also possible to horizontally center the
> image? There is a pretty straight-forward way to do it, used in the
> about-emacs screen.
I guess this could be done somehow. But do you want to center to make
the contents a bit larger and not to see the margins? If so, then
slicing to the bounding box (`s b') followed by fitting to width (`W')
may be the better approach.
Bye,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Wed, 06 Mar 2013 14:20:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 13887 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
This function gives the native pixel dimensions of an image:
(defun es-image-file-pixel-dimensions (file)
(let* ((type (image-type file nil nil))
(spec (list 'image :type type :file file)))
(image-size spec t)))
When
(> (getf (cdr (doc-view-current-image)) :width)
(car (es-image-file-pixel-dimensions
(getf (cdr (doc-view-current-image)) :file))))
there is quality loss.
What I don't want to see is margins having a different width - for the same
reasons you wouldn't put a photograph in a frame in the top left corner.
Ideally I'd also center vertically (should the image be shorter than the
window) and add a window-configuration-change-hook (or there might be
an appropriate display-spec), so it's always centered. Unfortunately no
image-viewer that currently comes with emacs (image-mode ,doc-view-mode
,image-dired-display-image-mode) does this.
Evgeni
On Wed, Mar 6, 2013 at 1:01 PM, Tassilo Horn <tsdh <at> gnu.org> wrote:
> E Sabof <esabof <at> gmail.com> writes:
>
> > I've tried it, indeed it works much better. Might it be possible to
> > store the the "native" size, and raise the resolution automatically
> > when the zoom exceeds it?
>
> Well, the resolution should be increased and the doc reconverted when
> the up-scaled image becomes blurry. But how should emacs know when you
> think it becomes blurry?
>
> > On a side note, might it be also possible to horizontally center the
> > image? There is a pretty straight-forward way to do it, used in the
> > about-emacs screen.
>
> I guess this could be done somehow. But do you want to center to make
> the contents a bit larger and not to see the margins? If so, then
> slicing to the bounding box (`s b') followed by fitting to width (`W')
> may be the better approach.
>
> Bye,
> Tassilo
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Wed, 06 Mar 2013 18:18:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 13887 <at> debbugs.gnu.org (full text, mbox):
> It tries to up-scale the available bitmap - leading to a loss
> of quality, instead of re-rendering the page from vector data.
In Emacs's trunk you can set doc-view-scale-internally to nil.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Wed, 06 Mar 2013 19:44:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 13887 <at> debbugs.gnu.org (full text, mbox):
E Sabof <esabof <at> gmail.com> writes:
> This function gives the native pixel dimensions of an image:
>
> (defun es-image-file-pixel-dimensions (file)
> (let* ((type (image-type file nil nil))
> (spec (list 'image :type type :file file)))
> (image-size spec t)))
>
> When
>
> (> (getf (cdr (doc-view-current-image)) :width)
> (car (es-image-file-pixel-dimensions
> (getf (cdr (doc-view-current-image)) :file))))
>
> there is quality loss.
Hm, ok. Maybe I'll give it a whirl.
> What I don't want to see is margins having a different width - for the
> same reasons you wouldn't put a photograph in a frame in the top left
> corner.
Could you test-drive this patch. It implements horizontal centering of
the image.
--8<---------------cut here---------------start------------->8---
=== modified file 'lisp/doc-view.el'
--- lisp/doc-view.el 2013-02-28 04:02:36 +0000
+++ lisp/doc-view.el 2013-03-06 19:35:43 +0000
@@ -1250,23 +1250,34 @@
(when doc-view-pending-cache-flush
(clear-image-cache)
(setq doc-view-pending-cache-flush nil))
- (let ((ol (doc-view-current-overlay))
- (image (if (and file (file-readable-p file))
- (if (not (and doc-view-scale-internally
- (fboundp 'imagemagick-types)))
- (apply 'create-image file doc-view--image-type nil args)
- (unless (member :width args)
- (setq args `(,@args :width ,doc-view-image-width)))
- (apply 'create-image file 'imagemagick nil args))))
- (slice (doc-view-current-slice)))
+ (let* ((ol (doc-view-current-overlay))
+ (image (if (and file (file-readable-p file))
+ (if (not (and doc-view-scale-internally
+ (fboundp 'imagemagick-types)))
+ (apply 'create-image file doc-view--image-type nil args)
+ (unless (member :width args)
+ (setq args `(,@args :width ,doc-view-image-width)))
+ (apply 'create-image file 'imagemagick nil args))))
+ (slice (doc-view-current-slice))
+ (img-width (car (image-size image)))
+ (displayed-img-width (if slice
+ (* (/ (float (nth 2 slice))
+ (car (image-size image 'pixels)))
+ img-width)
+ img-width))
+ (window-width (window-width (selected-window))))
(setf (doc-view-current-image) image)
(move-overlay ol (point-min) (point-max))
+ (when (> window-width displayed-img-width)
+ (overlay-put ol 'before-string
+ (propertize " " 'display
+ `(space :align-to (+ center (-0.5 . ,displayed-img-width))))))
(overlay-put ol 'display
(cond
(image
(if slice
(list (cons 'slice slice) image)
- image))
+ image))
;; We're trying to display a page that doesn't exist.
(doc-view-current-converter-processes
;; Maybe the page doesn't exist *yet*.
--8<---------------cut here---------------end--------------->8---
> Ideally I'd also center vertically (should the image be shorter than
> the window)
I think vertical centering is a bit more tricky since there's nothing
like :align-to or vertically stretchable spaces...
Bye,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Thu, 07 Mar 2013 15:19:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 13887 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I had a look at it, there are some issues with zooming. It doesn't work
when I open a document that is larger than the window, and sometimes in
other cases.
On Wed, Mar 6, 2013 at 7:43 PM, Tassilo Horn <tsdh <at> gnu.org> wrote:
> E Sabof <esabof <at> gmail.com> writes:
>
> > This function gives the native pixel dimensions of an image:
> >
> > (defun es-image-file-pixel-dimensions (file)
> > (let* ((type (image-type file nil nil))
> > (spec (list 'image :type type :file file)))
> > (image-size spec t)))
> >
> > When
> >
> > (> (getf (cdr (doc-view-current-image)) :width)
> > (car (es-image-file-pixel-dimensions
> > (getf (cdr (doc-view-current-image)) :file))))
> >
> > there is quality loss.
>
> Hm, ok. Maybe I'll give it a whirl.
>
> > What I don't want to see is margins having a different width - for the
> > same reasons you wouldn't put a photograph in a frame in the top left
> > corner.
>
> Could you test-drive this patch. It implements horizontal centering of
> the image.
>
> --8<---------------cut here---------------start------------->8---
> === modified file 'lisp/doc-view.el'
> --- lisp/doc-view.el 2013-02-28 04:02:36 +0000
> +++ lisp/doc-view.el 2013-03-06 19:35:43 +0000
> @@ -1250,23 +1250,34 @@
> (when doc-view-pending-cache-flush
> (clear-image-cache)
> (setq doc-view-pending-cache-flush nil))
> - (let ((ol (doc-view-current-overlay))
> - (image (if (and file (file-readable-p file))
> - (if (not (and doc-view-scale-internally
> - (fboundp 'imagemagick-types)))
> - (apply 'create-image file doc-view--image-type nil
> args)
> - (unless (member :width args)
> - (setq args `(,@args :width ,doc-view-image-width)))
> - (apply 'create-image file 'imagemagick nil args))))
> - (slice (doc-view-current-slice)))
> + (let* ((ol (doc-view-current-overlay))
> + (image (if (and file (file-readable-p file))
> + (if (not (and doc-view-scale-internally
> + (fboundp 'imagemagick-types)))
> + (apply 'create-image file doc-view--image-type nil
> args)
> + (unless (member :width args)
> + (setq args `(,@args :width ,doc-view-image-width)))
> + (apply 'create-image file 'imagemagick nil args))))
> + (slice (doc-view-current-slice))
> + (img-width (car (image-size image)))
> + (displayed-img-width (if slice
> + (* (/ (float (nth 2 slice))
> + (car (image-size image 'pixels)))
> + img-width)
> + img-width))
> + (window-width (window-width (selected-window))))
> (setf (doc-view-current-image) image)
> (move-overlay ol (point-min) (point-max))
> + (when (> window-width displayed-img-width)
> + (overlay-put ol 'before-string
> + (propertize " " 'display
> + `(space :align-to (+ center (-0.5 .
> ,displayed-img-width))))))
> (overlay-put ol 'display
> (cond
> (image
> (if slice
> (list (cons 'slice slice) image)
> - image))
> + image))
> ;; We're trying to display a page that doesn't exist.
> (doc-view-current-converter-processes
> ;; Maybe the page doesn't exist *yet*.
> --8<---------------cut here---------------end--------------->8---
>
> > Ideally I'd also center vertically (should the image be shorter than
> > the window)
>
> I think vertical centering is a bit more tricky since there's nothing
> like :align-to or vertically stretchable spaces...
>
> Bye,
> Tassilo
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Thu, 07 Mar 2013 15:57:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 13887 <at> debbugs.gnu.org (full text, mbox):
E Sabof <esabof <at> gmail.com> writes:
> I had a look at it, there are some issues with zooming. It doesn't
> work when I open a document that is larger than the window,
Does that mean that you'd like to set the hscoll when the window is
smaller than the images so that the center of the image is displayed at
the center of the window?
Hm, this could at least be done once when initially opening some
document. When switching pages, the current hscroll is preserved and I
consider that a good thing. It shouldn't re-center then.
> and sometimes in other cases.
I know there were some issues/errors when the image of a page isn't
there already. That should be fixed by this version of the patch.
--8<---------------cut here---------------start------------->8---
=== modified file 'lisp/doc-view.el'
--- lisp/doc-view.el 2013-02-28 04:02:36 +0000
+++ lisp/doc-view.el 2013-03-07 08:14:09 +0000
@@ -1250,7 +1250,7 @@
(when doc-view-pending-cache-flush
(clear-image-cache)
(setq doc-view-pending-cache-flush nil))
- (let ((ol (doc-view-current-overlay))
+ (let* ((ol (doc-view-current-overlay))
(image (if (and file (file-readable-p file))
(if (not (and doc-view-scale-internally
(fboundp 'imagemagick-types)))
@@ -1258,9 +1258,20 @@
(unless (member :width args)
(setq args `(,@args :width ,doc-view-image-width)))
(apply 'create-image file 'imagemagick nil args))))
- (slice (doc-view-current-slice)))
+ (slice (doc-view-current-slice))
+ (img-width (and image (car (image-size image))))
+ (displayed-img-width (if (and image slice)
+ (* (/ (float (nth 2 slice))
+ (car (image-size image 'pixels)))
+ img-width)
+ img-width))
+ (window-width (window-width (selected-window))))
(setf (doc-view-current-image) image)
(move-overlay ol (point-min) (point-max))
+ (when (and image (> window-width displayed-img-width))
+ (overlay-put ol 'before-string
+ (propertize " " 'display
+ `(space :align-to (+ center (-0.5 . ,displayed-img-width))))))
(overlay-put ol 'display
(cond
(image
--8<---------------cut here---------------end--------------->8---
Bye,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Thu, 07 Mar 2013 16:17:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 13887 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I mean pressing + or - moves the page horizontally, instead of changing the
size. I think the way it opens the document is ok.
I'll have a look at the patch and let you know.
Evgeni
On Thu, Mar 7, 2013 at 3:55 PM, Tassilo Horn <tsdh <at> gnu.org> wrote:
> E Sabof <esabof <at> gmail.com> writes:
>
> > I had a look at it, there are some issues with zooming. It doesn't
> > work when I open a document that is larger than the window,
>
> Does that mean that you'd like to set the hscoll when the window is
> smaller than the images so that the center of the image is displayed at
> the center of the window?
>
> Hm, this could at least be done once when initially opening some
> document. When switching pages, the current hscroll is preserved and I
> consider that a good thing. It shouldn't re-center then.
>
> > and sometimes in other cases.
>
> I know there were some issues/errors when the image of a page isn't
> there already. That should be fixed by this version of the patch.
>
> --8<---------------cut here---------------start------------->8---
> === modified file 'lisp/doc-view.el'
> --- lisp/doc-view.el 2013-02-28 04:02:36 +0000
> +++ lisp/doc-view.el 2013-03-07 08:14:09 +0000
> @@ -1250,7 +1250,7 @@
> (when doc-view-pending-cache-flush
> (clear-image-cache)
> (setq doc-view-pending-cache-flush nil))
> - (let ((ol (doc-view-current-overlay))
> + (let* ((ol (doc-view-current-overlay))
> (image (if (and file (file-readable-p file))
> (if (not (and doc-view-scale-internally
> (fboundp 'imagemagick-types)))
> @@ -1258,9 +1258,20 @@
> (unless (member :width args)
> (setq args `(,@args :width ,doc-view-image-width)))
> (apply 'create-image file 'imagemagick nil args))))
> - (slice (doc-view-current-slice)))
> + (slice (doc-view-current-slice))
> + (img-width (and image (car (image-size image))))
> + (displayed-img-width (if (and image slice)
> + (* (/ (float (nth 2 slice))
> + (car (image-size image 'pixels)))
> + img-width)
> + img-width))
> + (window-width (window-width (selected-window))))
> (setf (doc-view-current-image) image)
> (move-overlay ol (point-min) (point-max))
> + (when (and image (> window-width displayed-img-width))
> + (overlay-put ol 'before-string
> + (propertize " " 'display
> + `(space :align-to (+ center (-0.5 .
> ,displayed-img-width))))))
> (overlay-put ol 'display
> (cond
> (image
> --8<---------------cut here---------------end--------------->8---
>
> Bye,
> Tassilo
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Thu, 07 Mar 2013 22:59:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 13887 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Couldn't tell the difference to be honest.
Evgeni
On Thu, Mar 7, 2013 at 4:15 PM, E Sabof <esabof <at> gmail.com> wrote:
> I mean pressing + or - moves the page horizontally, instead of changing
> the size. I think the way it opens the document is ok.
>
> I'll have a look at the patch and let you know.
>
> Evgeni
>
>
> On Thu, Mar 7, 2013 at 3:55 PM, Tassilo Horn <tsdh <at> gnu.org> wrote:
>
>> E Sabof <esabof <at> gmail.com> writes:
>>
>> > I had a look at it, there are some issues with zooming. It doesn't
>> > work when I open a document that is larger than the window,
>>
>> Does that mean that you'd like to set the hscoll when the window is
>> smaller than the images so that the center of the image is displayed at
>> the center of the window?
>>
>> Hm, this could at least be done once when initially opening some
>> document. When switching pages, the current hscroll is preserved and I
>> consider that a good thing. It shouldn't re-center then.
>>
>> > and sometimes in other cases.
>>
>> I know there were some issues/errors when the image of a page isn't
>> there already. That should be fixed by this version of the patch.
>>
>> --8<---------------cut here---------------start------------->8---
>> === modified file 'lisp/doc-view.el'
>> --- lisp/doc-view.el 2013-02-28 04:02:36 +0000
>> +++ lisp/doc-view.el 2013-03-07 08:14:09 +0000
>> @@ -1250,7 +1250,7 @@
>> (when doc-view-pending-cache-flush
>> (clear-image-cache)
>> (setq doc-view-pending-cache-flush nil))
>> - (let ((ol (doc-view-current-overlay))
>> + (let* ((ol (doc-view-current-overlay))
>> (image (if (and file (file-readable-p file))
>> (if (not (and doc-view-scale-internally
>> (fboundp 'imagemagick-types)))
>> @@ -1258,9 +1258,20 @@
>> (unless (member :width args)
>> (setq args `(,@args :width ,doc-view-image-width)))
>> (apply 'create-image file 'imagemagick nil args))))
>> - (slice (doc-view-current-slice)))
>> + (slice (doc-view-current-slice))
>> + (img-width (and image (car (image-size image))))
>> + (displayed-img-width (if (and image slice)
>> + (* (/ (float (nth 2 slice))
>> + (car (image-size image 'pixels)))
>> + img-width)
>> + img-width))
>> + (window-width (window-width (selected-window))))
>> (setf (doc-view-current-image) image)
>> (move-overlay ol (point-min) (point-max))
>> + (when (and image (> window-width displayed-img-width))
>> + (overlay-put ol 'before-string
>> + (propertize " " 'display
>> + `(space :align-to (+ center (-0.5 .
>> ,displayed-img-width))))))
>> (overlay-put ol 'display
>> (cond
>> (image
>> --8<---------------cut here---------------end--------------->8---
>>
>> Bye,
>> Tassilo
>>
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Fri, 08 Mar 2013 07:59:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 13887 <at> debbugs.gnu.org (full text, mbox):
E Sabof <esabof <at> gmail.com> writes:
>> I mean pressing + or - moves the page horizontally, instead of
>> changing the size. I think the way it opens the document is ok.
Strange, I can't reproduce that here. Do you have a recipe?
> Couldn't tell the difference to be honest.
The difference between what? The old and the new patch?
Bye,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Sat, 09 Mar 2013 07:26:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 13887 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
---------- Forwarded message ----------
From: E Sabof <esabof <at> gmail.com>
Date: Sat, Mar 9, 2013 at 7:21 AM
Subject: Re: bug#13887: 24.3; doc-view will render blurry images when
image-magick is available
To: Tassilo Horn <tsdh <at> gnu.org>
Strange, I can't reproduce that here. Do you have a recipe?
>
Can't really give you a recipe - re-sizing just seems very fragile. A
possible source might be this: running M-: (overlays-at 1) usually returns
2 overlays. This is also true for the stable version.
The difference between what? The old and the new patch?
>
Yes
Evgeni
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Sat, 09 Mar 2013 07:28:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 13887 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
A relevant point might be that I usually start doc-view from
"dired-find-file"
Evgeni
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Mon, 11 Mar 2013 09:13:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 13887 <at> debbugs.gnu.org (full text, mbox):
E Sabof <esabof <at> gmail.com> writes:
> A relevant point might be that I usually start doc-view from
> "dired-find-file"
No, that seems unrelated.
>>> [Image seems to be moved only when zooming with my centering patch.]
>>
>> Strange, I can't reproduce that here. Do you have a recipe?
>
> Can't really give you a recipe - re-sizing just seems very fragile. A
> possible source might be this: running M-: (overlays-at 1) usually
> returns 2 overlays. This is also true for the stable version.
Hm, indeed. I can reproduce that with emacs -Q. Sometimes I have 2
overlays, sometimes even three. Right now, using emacs-bzr-version
"eliz <at> gnu.org-20130305181225-20nu9zkyby8jw21e",
$ emacs -Q some.pdf
will show some.pdf, and (overlays-at 1) returns 2 overlays. Also, when
switching pages, the mode-line indicator is updated but I still see the
old page. It won't refresh at all. Ditto for zooming or anything that
would change the display.
Aha, now I know how to reproduce that (also with the emacs with my
customizations and the centering patch). Somehow,
`doc-view-new-window-function' is run way too often (I've commented in
the (message ...) in its first line to see). When opening some
document, it's run twice. When the document is shown, M-x <TAB> will
also run it again. Ditto for M-: (i<TAB. Ditto for C-x C-f.
That way, I've managed to have 9 overlays all from 1 to point-max in my
current doc-view buffer. And now I get the same effects with zooming
(and my centering patch): it seems the image is just moved. The problem
is in fact that the :align-to changes for centering the image are
visible to you, while the image update is not. In that situation,
changing the page won't do anything visible for you, too, except for
updating the page number in the mode-line.
Stefan, could you please have a look at this? You're more proficient
when it comes to the windows/overlays/image-mode stuff.
Bye,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Mon, 11 Mar 2013 16:59:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 13887 <at> debbugs.gnu.org (full text, mbox):
> From: Tassilo Horn <tsdh <at> gnu.org>
> Date: Mon, 11 Mar 2013 10:11:28 +0100
> Cc: 13887 <at> debbugs.gnu.org
>
> Aha, now I know how to reproduce that (also with the emacs with my
> customizations and the centering patch). Somehow,
> `doc-view-new-window-function' is run way too often (I've commented in
> the (message ...) in its first line to see). When opening some
> document, it's run twice. When the document is shown, M-x <TAB> will
> also run it again. Ditto for M-: (i<TAB. Ditto for C-x C-f.
doc-view-new-window-function seems to be run from a
window-configuration-change-hook, right? If so, why do you expect it
to be run only once, or not run when you type "M-x TAB"? E.g., the
latter pops up the completion buffer and/or splits the window, which
constitutes a change in window configuration:
-- Variable: window-configuration-change-hook
A normal hook that is run every time you change the window
configuration of an existing frame. This includes splitting or
deleting windows, changing the sizes of windows, or displaying a
different buffer in a window. ^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I think a function written to run off that hook should be defensive
and not assume anything about when it will or won't be called, or how
many times. Just grep the C sources for
run_window_configuration_change_hook, and you will see why.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Mon, 11 Mar 2013 18:22:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 13887 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Aha, now I know how to reproduce that (also with the emacs with my
>> customizations and the centering patch). Somehow,
>> `doc-view-new-window-function' is run way too often (I've commented
>> in the (message ...) in its first line to see). When opening some
>> document, it's run twice. When the document is shown, M-x <TAB> will
>> also run it again. Ditto for M-: (i<TAB. Ditto for C-x C-f.
>
> doc-view-new-window-function seems to be run from a
> window-configuration-change-hook, right?
No, from `image-mode-new-window-functions'. The functions in there are
run by `image-mode-winprops' if (and only if) there are no winprops set
for the image and the current window. Basically, this should only ever
happen when there's a new window showing the buffer with the image.
Bye,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Mon, 11 Mar 2013 18:48:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 13887 <at> debbugs.gnu.org (full text, mbox):
> From: Tassilo Horn <tsdh <at> gnu.org>
> Cc: esabof <at> gmail.com, monnier <at> iro.umontreal.ca, 13887 <at> debbugs.gnu.org
> Date: Mon, 11 Mar 2013 19:20:47 +0100
>
> > doc-view-new-window-function seems to be run from a
> > window-configuration-change-hook, right?
>
> No, from `image-mode-new-window-functions'. The functions in there are
> run by `image-mode-winprops' if (and only if) there are no winprops set
> for the image and the current window.
Maybe I'm missing something, but in image-mode.el:
. image-mode-winprops is called by image-mode-reapply-winprops
. image-mode-reapply-winprops is added by image-mode-setup-winprops
to window-configuration-change-hook
Doesn't that mean what I said?
> Basically, this should only ever happen when there's a new window
> showing the buffer with the image.
How's that ensured? Can you walk us through the relevant code?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Mon, 11 Mar 2013 20:29:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 13887 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Tassilo Horn <tsdh <at> gnu.org>
>> Cc: esabof <at> gmail.com, monnier <at> iro.umontreal.ca, 13887 <at> debbugs.gnu.org
>> Date: Mon, 11 Mar 2013 19:20:47 +0100
>>
>> > doc-view-new-window-function seems to be run from a
>> > window-configuration-change-hook, right?
>>
>> No, from `image-mode-new-window-functions'. The functions in there
>> are run by `image-mode-winprops' if (and only if) there are no
>> winprops set for the image and the current window.
>
> Maybe I'm missing something, but in image-mode.el:
>
> . image-mode-winprops is called by image-mode-reapply-winprops
>
> . image-mode-reapply-winprops is added by image-mode-setup-winprops
> to window-configuration-change-hook
>
> Doesn't that mean what I said?
Nearly, except that `image-mode-new-window-functions' are only run when
they don't have an entry in `image-mode-winprops-alist'.
>> Basically, this should only ever happen when there's a new window
>> showing the buffer with the image.
>
> How's that ensured? Can you walk us through the relevant code?
That's line 72 in image-mode.el:
(let ((winprops (assq window image-mode-winprops-alist)))
;; For new windows, set defaults from the latest.
(unless winprops
(setq winprops (cons window
(copy-alist (cdar image-mode-winprops-alist))))
(run-hook-with-args 'image-mode-new-window-functions winprops))
However, whenever the doc-view window is split (e.g., when a completion
buffer pops up), the doc-view buffer is indeed shown in a new window.
That's why `doc-view-new-window-function' is run more often than I
expected originally.
That also explains why there are often multiple overlays in the doc-view
buffer. There's one overlay per window that has shown the buffer at
least once. This allows that you can have 2 windows displaying the same
doc-view buffer: one showing page X, and in the other you can switch to
other pages without changing the other window.
So the multiple overlays thingy is actually intended. But somewhere the
logic goes wonky and we're acting on the wrong overlay.
Bye,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Mon, 11 Mar 2013 21:01:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 13887 <at> debbugs.gnu.org (full text, mbox):
> From: Tassilo Horn <tsdh <at> gnu.org>
> Cc: esabof <at> gmail.com, monnier <at> iro.umontreal.ca, 13887 <at> debbugs.gnu.org
> Date: Mon, 11 Mar 2013 21:27:16 +0100
>
> So the multiple overlays thingy is actually intended. But somewhere the
> logic goes wonky and we're acting on the wrong overlay.
What is the "right" overlay?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Mon, 11 Mar 2013 22:10:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 13887 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Apparently overlays have a "window" property, which when set, will display
the overlay only in the relevant window.
I've noticed however that sometimes it gets set to t.
On Mon, Mar 11, 2013 at 8:59 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Tassilo Horn <tsdh <at> gnu.org>
> > Cc: esabof <at> gmail.com, monnier <at> iro.umontreal.ca, 13887 <at> debbugs.gnu.org
> > Date: Mon, 11 Mar 2013 21:27:16 +0100
> >
> > So the multiple overlays thingy is actually intended. But somewhere the
> > logic goes wonky and we're acting on the wrong overlay.
>
> What is the "right" overlay?
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Mon, 11 Mar 2013 23:43:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 13887 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
The overlay with t value has precedence over other overlays. If the problem
occurs, I can run the following function, and it will get fixed in existing
windows. However if I create a new window, it will show only text. If I
press + in that window, a new overlay will be created. Perhaps the t
overlay was meant to be the default, and someone misunderstood it's effect.
(defun 13887-fix-helper1 ()
(interactive)
(let* ((ovs (overlays-at (point)))
(ov-t (find-if (lambda (ov) (eq (overlay-get ov 'window) t))
ovs)))
(when ov-t (delete-overlay ov-t))))
Here is one more helper function which might be useful.
(defun 13887-own-overlay-present-p ()
(interactive)
(let* ((ovs (overlays-at (point))))
(find-if (lambda (ov) (eq (overlay-get ov 'window)
(selected-window)))
ovs)))
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Tue, 12 Mar 2013 01:02:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 13887 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Further evidence suggests that the "t taking precedence" version is wrong.
It's more probable the the precedence is determined by the order of
overlays in some C data-structure.
On Mon, Mar 11, 2013 at 11:41 PM, E Sabof <esabof <at> gmail.com> wrote:
> The overlay with t value has precedence over other overlays. If the
> problem occurs, I can run the following function, and it will get fixed in
> existing windows. However if I create a new window, it will show only text.
> If I press + in that window, a new overlay will be created. Perhaps the t
> overlay was meant to be the default, and someone misunderstood it's effect.
>
> (defun 13887-fix-helper1 ()
> (interactive)
> (let* ((ovs (overlays-at (point)))
> (ov-t (find-if (lambda (ov) (eq (overlay-get ov 'window) t))
> ovs)))
> (when ov-t (delete-overlay ov-t))))
>
> Here is one more helper function which might be useful.
>
> (defun 13887-own-overlay-present-p ()
> (interactive)
> (let* ((ovs (overlays-at (point))))
> (find-if (lambda (ov) (eq (overlay-get ov 'window)
> (selected-window)))
> ovs)))
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Tue, 12 Mar 2013 08:12:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 13887 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii writes:
> What is the "right" overlay?
There should be exactly one overlay in the doc-view buffer whose window
property is the currently selected window, and that window has this
overlay accociated in `image-mode-winprops-alist'.
E Sabof <esabof <at> gmail.com> writes:
> Further evidence suggests that the "t taking precedence" version is
> wrong. It's more probable the the precedence is determined by the
> order of overlays in some C data-structure.
I think the buffer-local value of `image-mode-winprops-alist' should
always look like:
--8<---------------cut here---------------start------------->8---
((#<window 0x846c030 on IncPat.pdf>
(overlay . #<overlay from 1 to 756769 in IncPat.pdf>)
(image image :type imagemagick :file "/tmp/docview1000/IncPat.pdf-982c2eddc6c753dafecbffecb17d5993/page-12.png" :width 685)
(info .
#("Page 12 of 13.\n" 0 14
(face bold)))
(page . 12)
(slice))
(t
(page . 1)
(overlay . #<overlay in no buffer>)))
--8<---------------cut here---------------end--------------->8---
That is, there's one entry for any window that shows this doc-view
buffer, plus one t-entry with a deleted overlay. The order of entries
is by recency of window activations (or creations?), I think. t is
always the last.
When `doc-view-new-window-function' is called for the very first time
for a new doc-view buffer (i.e., you opened a new document), (car
winprops) is t. I that case, a new overlay is created, doc-view and
window properties are added (both t), it's associated in winprops (the
t-entry), and then it's deleted so that its not shown (because at this
point in time the image to be shown might not exist). This entry acts
as default if there are no other entries.
Thereafter, it's immediately called again with a concrete window in (car
winprops). Don't ask me from where. I'm edebugging
`doc-view-new-window-function', but this call doesn't drop me in the
edebugger as the previous one did. I just see the message
New window #<window 0x7751d70 on foo.pdf> for buf foo.pdf
in the echo area.
With the second and any subsequent call of
`doc-view-new-window-function' for a given doc-view buffer, the overlay
of the top-entry in `image-mode-winprops-alist' is copied. That way,
the new window shows the same page with the same zoom level/slice as the
most recent other window showing the document.
Yesterday, when things were messed up, I know that
`image-mode-winprops-alist' looked like that:
--8<---------------cut here---------------start------------->8---
((#<window 0x846c030 on IncPat.pdf>
...)
(t
(page . 1)
(overlay . #<overlay from 1 to 756769 in IncPat.pdf>)))
--8<---------------cut here---------------end--------------->8---
That is, the t-entry had an overlay that hasn't been deleted. I don't
know how I could reach that state (I just quickly switched pages,
zoomed, sliced, split window), but that seems wrong and might be the
culprit because some other window in might already use that.
Bye,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Tue, 12 Mar 2013 16:53:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 13887 <at> debbugs.gnu.org (full text, mbox):
> From: Tassilo Horn <tsdh <at> gnu.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>, 13887 <at> debbugs.gnu.org
> Date: Tue, 12 Mar 2013 09:09:54 +0100
>
> Yesterday, when things were messed up, I know that
> `image-mode-winprops-alist' looked like that:
>
> --8<---------------cut here---------------start------------->8---
> ((#<window 0x846c030 on IncPat.pdf>
> ...)
> (t
> (page . 1)
> (overlay . #<overlay from 1 to 756769 in IncPat.pdf>)))
> --8<---------------cut here---------------end--------------->8---
>
> That is, the t-entry had an overlay that hasn't been deleted. I don't
> know how I could reach that state (I just quickly switched pages,
> zoomed, sliced, split window), but that seems wrong and might be the
> culprit because some other window in might already use that.
So is there still some issue with handling overlays or with display in
general?
You see, I chimed in because you seemed to indicate there's some
problems with how overlays are handled in this context. But now it
sounds like the problem is some fragile logic in doc-view.el proper,
right?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Tue, 12 Mar 2013 16:54:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 13887 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 12 Mar 2013 01:00:11 +0000
> From: E Sabof <esabof <at> gmail.com>
> Cc: Tassilo Horn <tsdh <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>, 13887 <at> debbugs.gnu.org
>
> Further evidence suggests that the "t taking precedence" version is wrong.
> It's more probable the the precedence is determined by the order of
> overlays in some C data-structure.
What do you mean by "precedence"? AFAIK, there's no precedence in
handling overlays, unless they have non-nil 'priority' property, in
which case all the overlays at a given position are sorted according
to priority before displaying them.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Tue, 12 Mar 2013 17:48:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 13887 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I mean which overlay will be visible, everything else being equal
On Tue, Mar 12, 2013 at 4:52 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > Date: Tue, 12 Mar 2013 01:00:11 +0000
> > From: E Sabof <esabof <at> gmail.com>
> > Cc: Tassilo Horn <tsdh <at> gnu.org>, Stefan Monnier <
> monnier <at> iro.umontreal.ca>, 13887 <at> debbugs.gnu.org
> >
> > Further evidence suggests that the "t taking precedence" version is
> wrong.
> > It's more probable the the precedence is determined by the order of
> > overlays in some C data-structure.
>
> What do you mean by "precedence"? AFAIK, there's no precedence in
> handling overlays, unless they have non-nil 'priority' property, in
> which case all the overlays at a given position are sorted according
> to priority before displaying them.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Tue, 12 Mar 2013 18:02:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 13887 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Yesterday, when things were messed up, I know that
>> `image-mode-winprops-alist' looked like that:
>>
>> --8<---------------cut here---------------start------------->8---
>> ((#<window 0x846c030 on IncPat.pdf>
>> ...)
>> (t
>> (page . 1)
>> (overlay . #<overlay from 1 to 756769 in IncPat.pdf>)))
>> --8<---------------cut here---------------end--------------->8---
>>
>> That is, the t-entry had an overlay that hasn't been deleted. I don't
>> know how I could reach that state (I just quickly switched pages,
>> zoomed, sliced, split window), but that seems wrong and might be the
>> culprit because some other window in might already use that.
>
> So is there still some issue with handling overlays or with display in
> general?
No, I don't think so.
> You see, I chimed in because you seemed to indicate there's some
> problems with how overlays are handled in this context. But now it
> sounds like the problem is some fragile logic in doc-view.el proper,
> right?
Yes, doc-view or (less likely) image-mode. That's why I've Cc-ed Stefan
who invented that logic.
Bye,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Tue, 12 Mar 2013 21:14:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 13887 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 12 Mar 2013 17:46:41 +0000
> From: E Sabof <esabof <at> gmail.com>
> Cc: Tassilo Horn <tsdh <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>, 13887 <at> debbugs.gnu.org
>
> I mean which overlay will be visible, everything else being equal
They all will be visible.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Thu, 14 Mar 2013 03:30:04 GMT)
Full text and
rfc822 format available.
Message #92 received at 13887 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Here is what I found:
The first time (doc-view-insert-image) is called, the doc-view buffer isn't
selected, and (doc-view-current-overlay) returns the t overlay.
The "fake" overlay gets "resurrected" when (doc-view-insert-image) calls
(move-overlay) on it.
Adding
(defun doc-view-initiate-display ()
;; Switch to image display if possible.
(if (doc-view-mode-p doc-view-doc-type)
(progn
+ (unless (eq (window-buffer) (current-buffer))
+ (set-window-buffer (selected-window) (current-buffer)))
prevents the t "window" from being set.
The second problem was that after splitting, new windows wouldn't have
overlays. What looked suspicious was that (image-mode-winprops) always ran
with the initial window. Changing the definition of
image-get-display-property from
(defun image-get-display-property ()
(get-char-property (point-min) 'display
;; There might be different images for different
displays.
(if (eq (window-buffer) (current-buffer))
(selected-window))))
to
(defun image-get-display-property ()
(or (get-char-property (point-min) 'display (selected-window))
(get-char-property (point-min) 'display)))
has fixed it. I'm not sure it's the right (only?) place to fix, since by
the time it gets called, (eq (window-buffer) (current-buffer)) should be
true.
Evgeni
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Thu, 14 Mar 2013 03:59:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 13887 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
However with these fixes, docview is no longer converts properly. It only
works if the images are cached.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Thu, 14 Mar 2013 07:26:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 13887 <at> debbugs.gnu.org (full text, mbox):
E Sabof <esabof <at> gmail.com> writes:
> The first time (doc-view-insert-image) is called, the doc-view buffer
> isn't selected, and (doc-view-current-overlay) returns the t overlay.
>
> The "fake" overlay gets "resurrected" when (doc-view-insert-image)
> calls (move-overlay) on it.
Thanks Evgeni, I think that brought me on track. Could you please
test-drive this patch (which also contains the centering stuff) and
check if the issue is fixed by it? It seems it is for me, but I only
did some very brief testing.
--8<---------------cut here---------------start------------->8---
=== modified file 'lisp/doc-view.el'
--- lisp/doc-view.el 2013-02-28 04:02:36 +0000
+++ lisp/doc-view.el 2013-03-14 07:21:18 +0000
@@ -1250,17 +1250,33 @@
(when doc-view-pending-cache-flush
(clear-image-cache)
(setq doc-view-pending-cache-flush nil))
- (let ((ol (doc-view-current-overlay))
- (image (if (and file (file-readable-p file))
+ (let ((ol (doc-view-current-overlay)))
+ ;; ol might be a deleted (see `doc-view-new-window-function'), in
+ ;; which case we don't want to modify it.
+ (when (overlay-buffer ol)
+ (let* ((image (if (and file (file-readable-p file))
(if (not (and doc-view-scale-internally
(fboundp 'imagemagick-types)))
(apply 'create-image file doc-view--image-type nil args)
(unless (member :width args)
(setq args `(,@args :width ,doc-view-image-width)))
(apply 'create-image file 'imagemagick nil args))))
- (slice (doc-view-current-slice)))
+ (slice (doc-view-current-slice))
+ (img-width (and image (car (image-size image))))
+ (displayed-img-width (if (and image slice)
+ (* (/ (float (nth 2 slice))
+ (car (image-size image 'pixels)))
+ img-width)
+ img-width))
+ (window-width (window-width (selected-window))))
(setf (doc-view-current-image) image)
(move-overlay ol (point-min) (point-max))
+ ;; In case the window is wider than the image, center the image
+ ;; horizontally.
+ (overlay-put ol 'before-string
+ (when (and image (> window-width displayed-img-width))
+ (propertize " " 'display
+ `(space :align-to (+ center (-0.5 . ,displayed-img-width))))))
(overlay-put ol 'display
(cond
(image
@@ -1287,7 +1303,7 @@
(vscroll (image-mode-window-get 'vscroll win)))
;; Reset scroll settings, in case they were changed.
(if hscroll (set-window-hscroll win hscroll))
- (if vscroll (set-window-vscroll win vscroll)))))))
+ (if vscroll (set-window-vscroll win vscroll)))))))))
(defun doc-view-sort (a b)
"Return non-nil if A should be sorted before B.
--8<---------------cut here---------------end--------------->8---
Bye,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Thu, 14 Mar 2013 13:28:01 GMT)
Full text and
rfc822 format available.
Message #101 received at 13887 <at> debbugs.gnu.org (full text, mbox):
> + (unless (eq (window-buffer) (current-buffer))
> + (set-window-buffer (selected-window) (current-buffer)))
This can't be the right fix: doc-view.el is just a major-mode that
controls how a particular buffer is displayed, and not which buffer to
display in which window.
[ I see Tassilo has a better patch already, so I'll let him take care of
it, but I just wanted to point out "the obvious". ]
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Thu, 14 Mar 2013 15:26:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 13887 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
With this patch I don't get an overlay in the initial window, and sometimes
after splitting. Redefining image-get-display-property as in my previous
patch fixes the splitting problem.
Evgeni
On Thu, Mar 14, 2013 at 7:24 AM, Tassilo Horn <tsdh <at> gnu.org> wrote:
> E Sabof <esabof <at> gmail.com> writes:
>
> > The first time (doc-view-insert-image) is called, the doc-view buffer
> > isn't selected, and (doc-view-current-overlay) returns the t overlay.
> >
> > The "fake" overlay gets "resurrected" when (doc-view-insert-image)
> > calls (move-overlay) on it.
>
> Thanks Evgeni, I think that brought me on track. Could you please
> test-drive this patch (which also contains the centering stuff) and
> check if the issue is fixed by it? It seems it is for me, but I only
> did some very brief testing.
>
> --8<---------------cut here---------------start------------->8---
> === modified file 'lisp/doc-view.el'
> --- lisp/doc-view.el 2013-02-28 04:02:36 +0000
> +++ lisp/doc-view.el 2013-03-14 07:21:18 +0000
> @@ -1250,17 +1250,33 @@
> (when doc-view-pending-cache-flush
> (clear-image-cache)
> (setq doc-view-pending-cache-flush nil))
> - (let ((ol (doc-view-current-overlay))
> - (image (if (and file (file-readable-p file))
> + (let ((ol (doc-view-current-overlay)))
> + ;; ol might be a deleted (see `doc-view-new-window-function'), in
> + ;; which case we don't want to modify it.
> + (when (overlay-buffer ol)
> + (let* ((image (if (and file (file-readable-p file))
> (if (not (and doc-view-scale-internally
> (fboundp 'imagemagick-types)))
> (apply 'create-image file doc-view--image-type nil
> args)
> (unless (member :width args)
> (setq args `(,@args :width ,doc-view-image-width)))
> (apply 'create-image file 'imagemagick nil args))))
> - (slice (doc-view-current-slice)))
> + (slice (doc-view-current-slice))
> + (img-width (and image (car (image-size image))))
> + (displayed-img-width (if (and image slice)
> + (* (/ (float (nth 2 slice))
> + (car (image-size image
> 'pixels)))
> + img-width)
> + img-width))
> + (window-width (window-width (selected-window))))
> (setf (doc-view-current-image) image)
> (move-overlay ol (point-min) (point-max))
> + ;; In case the window is wider than the image, center the image
> + ;; horizontally.
> + (overlay-put ol 'before-string
> + (when (and image (> window-width displayed-img-width))
> + (propertize " " 'display
> + `(space :align-to (+ center (-0.5 .
> ,displayed-img-width))))))
> (overlay-put ol 'display
> (cond
> (image
> @@ -1287,7 +1303,7 @@
> (vscroll (image-mode-window-get 'vscroll win)))
> ;; Reset scroll settings, in case they were changed.
> (if hscroll (set-window-hscroll win hscroll))
> - (if vscroll (set-window-vscroll win vscroll)))))))
> + (if vscroll (set-window-vscroll win vscroll)))))))))
>
> (defun doc-view-sort (a b)
> "Return non-nil if A should be sorted before B.
> --8<---------------cut here---------------end--------------->8---
>
> Bye,
> Tassilo
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Thu, 14 Mar 2013 15:32:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 13887 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> + (unless (eq (window-buffer) (current-buffer))
>> + (set-window-buffer (selected-window) (current-buffer)))
>
> This can't be the right fix: doc-view.el is just a major-mode that
> controls how a particular buffer is displayed, and not which buffer to
> display in which window.
>
> [ I see Tassilo has a better patch already, so I'll let him take care of
> it, but I just wanted to point out "the obvious". ]
I've committed my patch now. Evgeni, please report back if it really
solves the issue for you, so that I can close this issue.
Stefan, do you think the horizontal centering of images in case the
window is wider than the image should be customizable? Currently it's
not which is fine with me and is what other viewers also do.
Bye,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Thu, 14 Mar 2013 15:55:01 GMT)
Full text and
rfc822 format available.
Message #110 received at 13887 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Tested the trunk version of doc-view with "emacs -Q". I am still not
getting not getting an inital overlay. However I do get overlays after I
zoom and split. (I still get occasional pages with no overlays after
spltting if I use my default configuration)
Also If you zoom/split/delete windows for a while, doc-view stops centering
overlays in new windows.
Evgeni
On Thu, Mar 14, 2013 at 3:30 PM, Tassilo Horn <tsdh <at> gnu.org> wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
> >> + (unless (eq (window-buffer) (current-buffer))
> >> + (set-window-buffer (selected-window) (current-buffer)))
> >
> > This can't be the right fix: doc-view.el is just a major-mode that
> > controls how a particular buffer is displayed, and not which buffer to
> > display in which window.
> >
> > [ I see Tassilo has a better patch already, so I'll let him take care of
> > it, but I just wanted to point out "the obvious". ]
>
> I've committed my patch now. Evgeni, please report back if it really
> solves the issue for you, so that I can close this issue.
>
> Stefan, do you think the horizontal centering of images in case the
> window is wider than the image should be customizable? Currently it's
> not which is fine with me and is what other viewers also do.
>
> Bye,
> Tassilo
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Thu, 14 Mar 2013 16:22:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 13887 <at> debbugs.gnu.org (full text, mbox):
> Stefan, do you think the horizontal centering of images in case the
> window is wider than the image should be customizable?
I don't see a need for it, no. If we need more flexibility in this
area, I think the better option is to let the arrow keys move the
picture (i.e. reduce/increase the before-string space), but it's
a separate feature.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Thu, 14 Mar 2013 16:50:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 13887 <at> debbugs.gnu.org (full text, mbox):
E Sabof <esabof <at> gmail.com> writes:
> With this patch I don't get an overlay in the initial window, and
> sometimes after splitting.
Gosh, indeed! I'll look into that later.
Bye,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Thu, 14 Mar 2013 21:45:01 GMT)
Full text and
rfc822 format available.
Message #119 received at 13887 <at> debbugs.gnu.org (full text, mbox):
Tassilo Horn <tsdh <at> gnu.org> writes:
Hi again,
>> With this patch I don't get an overlay in the initial window, and
>> sometimes after splitting.
>
> Gosh, indeed! I'll look into that later.
Ok, now I really think I've fixed it (revno 112045), although I had to
add some obscure code in `doc-view-new-window-function' which adds
functions doing a display refresh to a timer. If I execute the code of
these functions directly in `doc-view-new-window-function', I get Lisp
nesting exceeds `max-lisp-eval-depth' errors.
Bye,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Fri, 15 Mar 2013 01:14:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 13887 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Now it works in "emacs -Q", but not with my configuration. To be honest I
don't think it's worth coding something final on top of current
image-mode's API - it looks under-developed at several points.
a) Is all the "window t" stuff necessary? Does anyone really care what is
"shown" in a buffer unless it's displayed in a window?
b) If yes, should "window t" be passed to a public hook?
c) Does (image-get-display-property) have any business asking what buffer
is currently selected in the window?
d) Why data is sometimes retrieved from the the buffer (as in (
image-get-display-property)), and sometimes from image-mode-winprops-alist
(as in (image-mode-winprops))? Is the complexity justified, or is one of
the methods "legacy"?
I use image viewers, so I could try re-factoring it, adding H/V centering,
improving zooming options, and extending the API.
Evgeni
On Thu, Mar 14, 2013 at 9:42 PM, Tassilo Horn <tsdh <at> gnu.org> wrote:
> Tassilo Horn <tsdh <at> gnu.org> writes:
>
> Hi again,
>
> >> With this patch I don't get an overlay in the initial window, and
> >> sometimes after splitting.
> >
> > Gosh, indeed! I'll look into that later.
>
> Ok, now I really think I've fixed it (revno 112045), although I had to
> add some obscure code in `doc-view-new-window-function' which adds
> functions doing a display refresh to a timer. If I execute the code of
> these functions directly in `doc-view-new-window-function', I get Lisp
> nesting exceeds `max-lisp-eval-depth' errors.
>
> Bye,
> Tassilo
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Fri, 15 Mar 2013 12:54:01 GMT)
Full text and
rfc822 format available.
Message #125 received at 13887 <at> debbugs.gnu.org (full text, mbox):
> a) Is all the "window t" stuff necessary?
> Does anyone really care what is "shown" in a buffer unless it's
> displayed in a window?
It's not a question of caring: it's a mechanism.
If you "move to next page" before displaying the buffer, then yes, you
probably care. In most cases you don't, but then this "window t stuff"
shouldn't hurt you one bit either.
> c) Does (image-get-display-property) have any business asking what buffer
> is currently selected in the window?
Good question. It shouldn't hurt, but maybe it's a mistake.
> d) Why data is sometimes retrieved from the the buffer (as in (
> image-get-display-property)), and sometimes from image-mode-winprops-alist
> (as in (image-mode-winprops))? Is the complexity justified, or is one of
> the methods "legacy"?
Can't remember, sorry. That's a good question, tho.
I do remember that part of the motivation behind the design was that:
- several windows need to be able to display different pages (or
different parts of the same page) of the same doc-view buffer.
- "current page and page position" info needs to be preserved while the
buffer is not shown, so that you can temporarily switch to some other
buffer and then switch back to the doc-view buffer without finding
yourself back at page 1.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Fri, 15 Mar 2013 13:36:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 13887 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Mar 15, 2013 at 12:52 PM, Stefan Monnier
<monnier <at> iro.umontreal.ca>wrote:
> > a) Is all the "window t" stuff necessary?
> > Does anyone really care what is "shown" in a buffer unless it's
> > displayed in a window?
>
> It's not a question of caring: it's a mechanism.
>
> If you "move to next page" before displaying the buffer, then yes, you
> probably care. In most cases you don't, but then this "window t stuff"
> shouldn't hurt you one bit either.
I should have said "associated" instead of "displayed".
What I'm trying to say is that a certain window is always selected. If a
buffer is not being displayed, I associate data with the selected window,
and later show it in the same window, the right thing should happen. If I
display it in a different window. Either a) The window already has data, so
it will be used. b) The window doesn't have data, so it will take data I
have just set.
I think the above behavior is acceptable. I don't know if it's any
different from the current.
Evgeni
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Fri, 15 Mar 2013 13:58:01 GMT)
Full text and
rfc822 format available.
Message #131 received at 13887 <at> debbugs.gnu.org (full text, mbox):
E Sabof <esabof <at> gmail.com> writes:
> Now it works in "emacs -Q", but not with my configuration.
Do you mind to share your configuration?
Bye,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Fri, 15 Mar 2013 14:11:01 GMT)
Full text and
rfc822 format available.
Message #134 received at 13887 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I've checked again, sometimes it works, sometimes it doesn't.
My configuration is rather large. It would be a lot easier for me to try
and find the differences than for someone else.
Evgeni
On Fri, Mar 15, 2013 at 1:55 PM, Tassilo Horn <tsdh <at> gnu.org> wrote:
> E Sabof <esabof <at> gmail.com> writes:
>
> > Now it works in "emacs -Q", but not with my configuration.
>
> Do you mind to share your configuration?
>
> Bye,
> Tassilo
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Fri, 15 Mar 2013 17:53:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 13887 <at> debbugs.gnu.org (full text, mbox):
> What I'm trying to say is that a certain window is always selected. If a
> buffer is not being displayed, I associate data with the selected window,
> and later show it in the same window, the right thing should happen. If I
> display it in a different window. Either a) The window already has data, so
> it will be used. b) The window doesn't have data, so it will take data I
> have just set.
> I think the above behavior is acceptable.
It's probably fine as well, yes.
> I don't know if it's any different from the current.
It probably is in various corner cases. Not sure if it matters.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Fri, 15 Mar 2013 23:28:02 GMT)
Full text and
rfc822 format available.
Message #140 received at 13887 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Should I try to patch it? Without "window t" image-mode would be more
predictable.
Evgeni
On Fri, Mar 15, 2013 at 5:51 PM, Stefan Monnier <monnier <at> iro.umontreal.ca>wrote:
> > What I'm trying to say is that a certain window is always selected. If a
> > buffer is not being displayed, I associate data with the selected window,
> > and later show it in the same window, the right thing should happen. If I
> > display it in a different window. Either a) The window already has data,
> so
> > it will be used. b) The window doesn't have data, so it will take data I
> > have just set.
> > I think the above behavior is acceptable.
>
> It's probably fine as well, yes.
>
> > I don't know if it's any different from the current.
>
> It probably is in various corner cases. Not sure if it matters.
>
>
> Stefan
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Sat, 16 Mar 2013 13:43:02 GMT)
Full text and
rfc822 format available.
Message #143 received at 13887 <at> debbugs.gnu.org (full text, mbox):
> Should I try to patch it? Without "window t" image-mode would be more
> predictable.
I don't know.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Sat, 16 Mar 2013 23:33:01 GMT)
Full text and
rfc822 format available.
Message #146 received at 13887 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
There is a case where I initialize a mode in one window, show it in another,
move down several pages, and then switch to the buffer in the first window
(and
the first page will be shown instead of the current).
If my understanding is correct, initialization is the only place in which
the
behavior of "window t" is evident and beneficial.
I'm not sure what I dislike the least. "window t" and the need to track
window-buffer, a dedicated initialization mechanism, or switching to "fully
initialized mode" the first time a real window is processed.
I suppose I could try finding what goes wrong with the current patch in the
meanwhile. I think that my previous experiment suggests a confusion
regarding
the value of (window-buffer) is a likely cause of this bug.
Evgeni
On Sat, Mar 16, 2013 at 1:41 PM, Stefan Monnier <monnier <at> iro.umontreal.ca>wrote:
> > Should I try to patch it? Without "window t" image-mode would be more
> > predictable.
>
> I don't know.
>
>
> Stefan
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Wed, 20 Mar 2013 16:01:05 GMT)
Full text and
rfc822 format available.
Message #149 received at 13887 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
It sometimes happens when the images are retrieved from cache. I'll try
to simplify my config a bit, and send you a link in a PM.
Evgeni
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Thu, 26 Sep 2019 17:17:01 GMT)
Full text and
rfc822 format available.
Message #152 received at 13887 <at> debbugs.gnu.org (full text, mbox):
E Sabof <esabof <at> gmail.com> writes:
> It sometimes happens when the images are retrieved from cache. I'll try to
> simplify my config a bit, and send you a link in a PM.
This the last entry in this very long bug report. I'm not sure whether
everything was resolved or not, though: doc-view-scale-internally was
added, which should help with some of these problems.
PDFs render well for me.
Are you still seeing these problems in Emacs 27?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Thu, 26 Sep 2019 17:17:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13887; Package
emacs.
(Mon, 14 Oct 2019 06:05:02 GMT)
Full text and
rfc822 format available.
Message #157 received at 13887 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> E Sabof <esabof <at> gmail.com> writes:
>
>> It sometimes happens when the images are retrieved from cache. I'll try to
>> simplify my config a bit, and send you a link in a PM.
>
> This the last entry in this very long bug report. I'm not sure whether
> everything was resolved or not, though: doc-view-scale-internally was
> added, which should help with some of these problems.
>
> PDFs render well for me.
>
> Are you still seeing these problems in Emacs 27?
More information was requested some weeks back, but no response was
given, so I'm closing this bug report. If you're still seeing this
problem, please reopen.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
13887 <at> debbugs.gnu.org and E Sabof <esabof <at> gmail.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Mon, 14 Oct 2019 06:05:04 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 11 Nov 2019 12:24:14 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 223 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.