* bug#13887: 24.3; doc-view will render blurry images when image-magick is available @ 2013-03-06 3:40 E Sabof 2013-03-06 8:05 ` Tassilo Horn 2013-03-06 18:16 ` Stefan Monnier 0 siblings, 2 replies; 51+ messages in thread From: E Sabof @ 2013-03-06 3:40 UTC (permalink / raw) To: 13887 [-- Attachment #1: Type: text/plain, Size: 125 bytes --] It tries to up-scale the available bitmap - leading to a loss of quality, instead of re-rendering the page from vector data. [-- Attachment #2: Type: text/html, Size: 147 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-06 3:40 bug#13887: 24.3; doc-view will render blurry images when image-magick is available E Sabof @ 2013-03-06 8:05 ` Tassilo Horn 2013-03-06 12:13 ` E Sabof 2013-03-06 18:16 ` Stefan Monnier 1 sibling, 1 reply; 51+ messages in thread From: Tassilo Horn @ 2013-03-06 8:05 UTC (permalink / raw) To: E Sabof; +Cc: 13887 E Sabof <esabof@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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-06 8:05 ` Tassilo Horn @ 2013-03-06 12:13 ` E Sabof 2013-03-06 13:01 ` Tassilo Horn 0 siblings, 1 reply; 51+ messages in thread From: E Sabof @ 2013-03-06 12:13 UTC (permalink / raw) To: Tassilo Horn; +Cc: 13887 [-- Attachment #1: Type: text/plain, Size: 886 bytes --] 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@gnu.org> wrote: > E Sabof <esabof@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 > [-- Attachment #2: Type: text/html, Size: 1369 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-06 12:13 ` E Sabof @ 2013-03-06 13:01 ` Tassilo Horn 2013-03-06 14:19 ` E Sabof 0 siblings, 1 reply; 51+ messages in thread From: Tassilo Horn @ 2013-03-06 13:01 UTC (permalink / raw) To: E Sabof; +Cc: 13887 E Sabof <esabof@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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-06 13:01 ` Tassilo Horn @ 2013-03-06 14:19 ` E Sabof 2013-03-06 19:43 ` Tassilo Horn 0 siblings, 1 reply; 51+ messages in thread From: E Sabof @ 2013-03-06 14:19 UTC (permalink / raw) To: Tassilo Horn; +Cc: 13887 [-- Attachment #1: Type: text/plain, Size: 1790 bytes --] 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@gnu.org> wrote: > E Sabof <esabof@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 > [-- Attachment #2: Type: text/html, Size: 2570 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-06 14:19 ` E Sabof @ 2013-03-06 19:43 ` Tassilo Horn 2013-03-07 15:17 ` E Sabof 0 siblings, 1 reply; 51+ messages in thread From: Tassilo Horn @ 2013-03-06 19:43 UTC (permalink / raw) To: E Sabof; +Cc: 13887 E Sabof <esabof@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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-06 19:43 ` Tassilo Horn @ 2013-03-07 15:17 ` E Sabof 2013-03-07 15:55 ` Tassilo Horn 0 siblings, 1 reply; 51+ messages in thread From: E Sabof @ 2013-03-07 15:17 UTC (permalink / raw) To: Tassilo Horn; +Cc: 13887 [-- Attachment #1: Type: text/plain, Size: 3950 bytes --] 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@gnu.org> wrote: > E Sabof <esabof@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 > [-- Attachment #2: Type: text/html, Size: 4794 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-07 15:17 ` E Sabof @ 2013-03-07 15:55 ` Tassilo Horn 2013-03-07 16:15 ` E Sabof 0 siblings, 1 reply; 51+ messages in thread From: Tassilo Horn @ 2013-03-07 15:55 UTC (permalink / raw) To: E Sabof; +Cc: 13887 E Sabof <esabof@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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-07 15:55 ` Tassilo Horn @ 2013-03-07 16:15 ` E Sabof 2013-03-07 22:57 ` E Sabof 0 siblings, 1 reply; 51+ messages in thread From: E Sabof @ 2013-03-07 16:15 UTC (permalink / raw) To: Tassilo Horn; +Cc: 13887 [-- Attachment #1: Type: text/plain, Size: 2848 bytes --] 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@gnu.org> wrote: > E Sabof <esabof@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 > [-- Attachment #2: Type: text/html, Size: 3714 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-07 16:15 ` E Sabof @ 2013-03-07 22:57 ` E Sabof 2013-03-08 7:57 ` Tassilo Horn 0 siblings, 1 reply; 51+ messages in thread From: E Sabof @ 2013-03-07 22:57 UTC (permalink / raw) To: Tassilo Horn; +Cc: 13887 [-- Attachment #1: Type: text/plain, Size: 3046 bytes --] Couldn't tell the difference to be honest. Evgeni On Thu, Mar 7, 2013 at 4:15 PM, E Sabof <esabof@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@gnu.org> wrote: > >> E Sabof <esabof@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 >> > > [-- Attachment #2: Type: text/html, Size: 4194 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-07 22:57 ` E Sabof @ 2013-03-08 7:57 ` Tassilo Horn [not found] ` <CAEp6DybMJkagHjRaXPiA_ED_dntOk=5USr+P9DfqRPZ_JrrKww@mail.gmail.com> 0 siblings, 1 reply; 51+ messages in thread From: Tassilo Horn @ 2013-03-08 7:57 UTC (permalink / raw) To: E Sabof; +Cc: 13887 E Sabof <esabof@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 ^ permalink raw reply [flat|nested] 51+ messages in thread
[parent not found: <CAEp6DybMJkagHjRaXPiA_ED_dntOk=5USr+P9DfqRPZ_JrrKww@mail.gmail.com>]
* bug#13887: Fwd: bug#13887: 24.3; doc-view will render blurry images when image-magick is available [not found] ` <CAEp6DybMJkagHjRaXPiA_ED_dntOk=5USr+P9DfqRPZ_JrrKww@mail.gmail.com> @ 2013-03-09 7:25 ` E Sabof 2013-03-09 7:26 ` E Sabof 0 siblings, 1 reply; 51+ messages in thread From: E Sabof @ 2013-03-09 7:25 UTC (permalink / raw) To: 13887 [-- Attachment #1: Type: text/plain, Size: 573 bytes --] ---------- Forwarded message ---------- From: E Sabof <esabof@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@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 [-- Attachment #2: Type: text/html, Size: 1520 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-09 7:25 ` bug#13887: Fwd: " E Sabof @ 2013-03-09 7:26 ` E Sabof 2013-03-11 9:11 ` Tassilo Horn 0 siblings, 1 reply; 51+ messages in thread From: E Sabof @ 2013-03-09 7:26 UTC (permalink / raw) To: 13887, Tassilo Horn [-- Attachment #1: Type: text/plain, Size: 87 bytes --] A relevant point might be that I usually start doc-view from "dired-find-file" Evgeni [-- Attachment #2: Type: text/html, Size: 148 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-09 7:26 ` E Sabof @ 2013-03-11 9:11 ` Tassilo Horn 2013-03-11 16:57 ` Eli Zaretskii 0 siblings, 1 reply; 51+ messages in thread From: Tassilo Horn @ 2013-03-11 9:11 UTC (permalink / raw) To: E Sabof, Stefan Monnier; +Cc: 13887 E Sabof <esabof@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@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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-11 9:11 ` Tassilo Horn @ 2013-03-11 16:57 ` Eli Zaretskii 2013-03-11 18:20 ` Tassilo Horn 0 siblings, 1 reply; 51+ messages in thread From: Eli Zaretskii @ 2013-03-11 16:57 UTC (permalink / raw) To: Tassilo Horn; +Cc: 13887, esabof > From: Tassilo Horn <tsdh@gnu.org> > Date: Mon, 11 Mar 2013 10:11:28 +0100 > Cc: 13887@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. ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-11 16:57 ` Eli Zaretskii @ 2013-03-11 18:20 ` Tassilo Horn 2013-03-11 18:45 ` Eli Zaretskii 0 siblings, 1 reply; 51+ messages in thread From: Tassilo Horn @ 2013-03-11 18:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13887, esabof Eli Zaretskii <eliz@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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-11 18:20 ` Tassilo Horn @ 2013-03-11 18:45 ` Eli Zaretskii 2013-03-11 20:27 ` Tassilo Horn 0 siblings, 1 reply; 51+ messages in thread From: Eli Zaretskii @ 2013-03-11 18:45 UTC (permalink / raw) To: Tassilo Horn; +Cc: 13887, esabof > From: Tassilo Horn <tsdh@gnu.org> > Cc: esabof@gmail.com, monnier@iro.umontreal.ca, 13887@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? ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-11 18:45 ` Eli Zaretskii @ 2013-03-11 20:27 ` Tassilo Horn 2013-03-11 20:59 ` Eli Zaretskii 0 siblings, 1 reply; 51+ messages in thread From: Tassilo Horn @ 2013-03-11 20:27 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13887, esabof Eli Zaretskii <eliz@gnu.org> writes: >> From: Tassilo Horn <tsdh@gnu.org> >> Cc: esabof@gmail.com, monnier@iro.umontreal.ca, 13887@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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-11 20:27 ` Tassilo Horn @ 2013-03-11 20:59 ` Eli Zaretskii 2013-03-11 22:08 ` E Sabof 0 siblings, 1 reply; 51+ messages in thread From: Eli Zaretskii @ 2013-03-11 20:59 UTC (permalink / raw) To: Tassilo Horn; +Cc: 13887, esabof > From: Tassilo Horn <tsdh@gnu.org> > Cc: esabof@gmail.com, monnier@iro.umontreal.ca, 13887@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? ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-11 20:59 ` Eli Zaretskii @ 2013-03-11 22:08 ` E Sabof 2013-03-11 23:41 ` E Sabof 0 siblings, 1 reply; 51+ messages in thread From: E Sabof @ 2013-03-11 22:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13887, Tassilo Horn [-- Attachment #1: Type: text/plain, Size: 575 bytes --] 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@gnu.org> wrote: > > From: Tassilo Horn <tsdh@gnu.org> > > Cc: esabof@gmail.com, monnier@iro.umontreal.ca, 13887@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? > [-- Attachment #2: Type: text/html, Size: 1180 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-11 22:08 ` E Sabof @ 2013-03-11 23:41 ` E Sabof 2013-03-12 1:00 ` E Sabof 0 siblings, 1 reply; 51+ messages in thread From: E Sabof @ 2013-03-11 23:41 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13887, Tassilo Horn [-- Attachment #1: Type: text/plain, Size: 867 bytes --] 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))) [-- Attachment #2: Type: text/html, Size: 1551 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-11 23:41 ` E Sabof @ 2013-03-12 1:00 ` E Sabof 2013-03-12 8:09 ` Tassilo Horn 2013-03-12 16:52 ` Eli Zaretskii 0 siblings, 2 replies; 51+ messages in thread From: E Sabof @ 2013-03-12 1:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13887, Tassilo Horn [-- Attachment #1: Type: text/plain, Size: 1157 bytes --] 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@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))) > [-- Attachment #2: Type: text/html, Size: 2094 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-12 1:00 ` E Sabof @ 2013-03-12 8:09 ` Tassilo Horn 2013-03-12 16:50 ` Eli Zaretskii 2013-03-12 16:52 ` Eli Zaretskii 1 sibling, 1 reply; 51+ messages in thread From: Tassilo Horn @ 2013-03-12 8:09 UTC (permalink / raw) To: E Sabof; +Cc: 13887 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@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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-12 8:09 ` Tassilo Horn @ 2013-03-12 16:50 ` Eli Zaretskii 2013-03-12 18:00 ` Tassilo Horn 0 siblings, 1 reply; 51+ messages in thread From: Eli Zaretskii @ 2013-03-12 16:50 UTC (permalink / raw) To: Tassilo Horn; +Cc: 13887, esabof > From: Tassilo Horn <tsdh@gnu.org> > Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>, 13887@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? ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-12 16:50 ` Eli Zaretskii @ 2013-03-12 18:00 ` Tassilo Horn 0 siblings, 0 replies; 51+ messages in thread From: Tassilo Horn @ 2013-03-12 18:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13887, esabof Eli Zaretskii <eliz@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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-12 1:00 ` E Sabof 2013-03-12 8:09 ` Tassilo Horn @ 2013-03-12 16:52 ` Eli Zaretskii 2013-03-12 17:46 ` E Sabof 1 sibling, 1 reply; 51+ messages in thread From: Eli Zaretskii @ 2013-03-12 16:52 UTC (permalink / raw) To: E Sabof; +Cc: 13887, tsdh > Date: Tue, 12 Mar 2013 01:00:11 +0000 > From: E Sabof <esabof@gmail.com> > Cc: Tassilo Horn <tsdh@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>, 13887@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. ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-12 16:52 ` Eli Zaretskii @ 2013-03-12 17:46 ` E Sabof 2013-03-12 21:11 ` Eli Zaretskii 0 siblings, 1 reply; 51+ messages in thread From: E Sabof @ 2013-03-12 17:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13887, Tassilo Horn [-- Attachment #1: Type: text/plain, Size: 769 bytes --] I mean which overlay will be visible, everything else being equal On Tue, Mar 12, 2013 at 4:52 PM, Eli Zaretskii <eliz@gnu.org> wrote: > > Date: Tue, 12 Mar 2013 01:00:11 +0000 > > From: E Sabof <esabof@gmail.com> > > Cc: Tassilo Horn <tsdh@gnu.org>, Stefan Monnier < > monnier@iro.umontreal.ca>, 13887@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. > [-- Attachment #2: Type: text/html, Size: 1409 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-12 17:46 ` E Sabof @ 2013-03-12 21:11 ` Eli Zaretskii 2013-03-14 3:28 ` E Sabof 0 siblings, 1 reply; 51+ messages in thread From: Eli Zaretskii @ 2013-03-12 21:11 UTC (permalink / raw) To: E Sabof; +Cc: 13887, tsdh > Date: Tue, 12 Mar 2013 17:46:41 +0000 > From: E Sabof <esabof@gmail.com> > Cc: Tassilo Horn <tsdh@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>, 13887@debbugs.gnu.org > > I mean which overlay will be visible, everything else being equal They all will be visible. ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-12 21:11 ` Eli Zaretskii @ 2013-03-14 3:28 ` E Sabof 2013-03-14 3:56 ` E Sabof ` (2 more replies) 0 siblings, 3 replies; 51+ messages in thread From: E Sabof @ 2013-03-14 3:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13887, Tassilo Horn [-- Attachment #1: Type: text/plain, Size: 1381 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 1981 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-14 3:28 ` E Sabof @ 2013-03-14 3:56 ` E Sabof 2013-03-14 7:24 ` Tassilo Horn 2013-03-14 13:26 ` Stefan Monnier 2 siblings, 0 replies; 51+ messages in thread From: E Sabof @ 2013-03-14 3:56 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13887, Tassilo Horn [-- Attachment #1: Type: text/plain, Size: 106 bytes --] However with these fixes, docview is no longer converts properly. It only works if the images are cached. [-- Attachment #2: Type: text/html, Size: 127 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-14 3:28 ` E Sabof 2013-03-14 3:56 ` E Sabof @ 2013-03-14 7:24 ` Tassilo Horn 2013-03-14 15:23 ` E Sabof 2013-03-14 13:26 ` Stefan Monnier 2 siblings, 1 reply; 51+ messages in thread From: Tassilo Horn @ 2013-03-14 7:24 UTC (permalink / raw) To: E Sabof; +Cc: 13887 E Sabof <esabof@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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-14 7:24 ` Tassilo Horn @ 2013-03-14 15:23 ` E Sabof 2013-03-14 16:48 ` Tassilo Horn 0 siblings, 1 reply; 51+ messages in thread From: E Sabof @ 2013-03-14 15:23 UTC (permalink / raw) To: Tassilo Horn; +Cc: 13887 [-- Attachment #1: Type: text/plain, Size: 3536 bytes --] 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@gnu.org> wrote: > E Sabof <esabof@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 > [-- Attachment #2: Type: text/html, Size: 4674 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-14 15:23 ` E Sabof @ 2013-03-14 16:48 ` Tassilo Horn 2013-03-14 21:42 ` Tassilo Horn 0 siblings, 1 reply; 51+ messages in thread From: Tassilo Horn @ 2013-03-14 16:48 UTC (permalink / raw) To: E Sabof; +Cc: 13887 E Sabof <esabof@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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-14 16:48 ` Tassilo Horn @ 2013-03-14 21:42 ` Tassilo Horn 2013-03-15 1:11 ` E Sabof 0 siblings, 1 reply; 51+ messages in thread From: Tassilo Horn @ 2013-03-14 21:42 UTC (permalink / raw) To: E Sabof; +Cc: 13887 Tassilo Horn <tsdh@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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-14 21:42 ` Tassilo Horn @ 2013-03-15 1:11 ` E Sabof 2013-03-15 12:52 ` Stefan Monnier 2013-03-15 13:55 ` Tassilo Horn 0 siblings, 2 replies; 51+ messages in thread From: E Sabof @ 2013-03-15 1:11 UTC (permalink / raw) To: Tassilo Horn; +Cc: 13887 [-- Attachment #1: Type: text/plain, Size: 1506 bytes --] 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@gnu.org> wrote: > Tassilo Horn <tsdh@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 > [-- Attachment #2: Type: text/html, Size: 2744 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-15 1:11 ` E Sabof @ 2013-03-15 12:52 ` Stefan Monnier 2013-03-15 13:34 ` E Sabof 2013-03-15 13:55 ` Tassilo Horn 1 sibling, 1 reply; 51+ messages in thread From: Stefan Monnier @ 2013-03-15 12:52 UTC (permalink / raw) To: E Sabof; +Cc: 13887, Tassilo Horn > 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-15 12:52 ` Stefan Monnier @ 2013-03-15 13:34 ` E Sabof 2013-03-15 17:51 ` Stefan Monnier 0 siblings, 1 reply; 51+ messages in thread From: E Sabof @ 2013-03-15 13:34 UTC (permalink / raw) To: Stefan Monnier; +Cc: 13887, Tassilo Horn [-- Attachment #1: Type: text/plain, Size: 1011 bytes --] On Fri, Mar 15, 2013 at 12:52 PM, Stefan Monnier <monnier@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 [-- Attachment #2: Type: text/html, Size: 1609 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-15 13:34 ` E Sabof @ 2013-03-15 17:51 ` Stefan Monnier 2013-03-15 23:26 ` E Sabof 0 siblings, 1 reply; 51+ messages in thread From: Stefan Monnier @ 2013-03-15 17:51 UTC (permalink / raw) To: E Sabof; +Cc: 13887, Tassilo Horn > 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-15 17:51 ` Stefan Monnier @ 2013-03-15 23:26 ` E Sabof 2013-03-16 13:41 ` Stefan Monnier 0 siblings, 1 reply; 51+ messages in thread From: E Sabof @ 2013-03-15 23:26 UTC (permalink / raw) To: Stefan Monnier; +Cc: 13887, Tassilo Horn [-- Attachment #1: Type: text/plain, Size: 820 bytes --] 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@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 > [-- Attachment #2: Type: text/html, Size: 1359 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-15 23:26 ` E Sabof @ 2013-03-16 13:41 ` Stefan Monnier 2013-03-16 23:30 ` E Sabof 0 siblings, 1 reply; 51+ messages in thread From: Stefan Monnier @ 2013-03-16 13:41 UTC (permalink / raw) To: E Sabof; +Cc: 13887, Tassilo Horn > Should I try to patch it? Without "window t" image-mode would be more > predictable. I don't know. Stefan ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-16 13:41 ` Stefan Monnier @ 2013-03-16 23:30 ` E Sabof 0 siblings, 0 replies; 51+ messages in thread From: E Sabof @ 2013-03-16 23:30 UTC (permalink / raw) To: Stefan Monnier; +Cc: 13887, Tassilo Horn [-- Attachment #1: Type: text/plain, Size: 989 bytes --] 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@iro.umontreal.ca>wrote: > > Should I try to patch it? Without "window t" image-mode would be more > > predictable. > > I don't know. > > > Stefan > [-- Attachment #2: Type: text/html, Size: 1634 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-15 1:11 ` E Sabof 2013-03-15 12:52 ` Stefan Monnier @ 2013-03-15 13:55 ` Tassilo Horn 2013-03-15 14:08 ` E Sabof 2013-03-20 15:58 ` E Sabof 1 sibling, 2 replies; 51+ messages in thread From: Tassilo Horn @ 2013-03-15 13:55 UTC (permalink / raw) To: E Sabof; +Cc: 13887 E Sabof <esabof@gmail.com> writes: > Now it works in "emacs -Q", but not with my configuration. Do you mind to share your configuration? Bye, Tassilo ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-15 13:55 ` Tassilo Horn @ 2013-03-15 14:08 ` E Sabof 2013-03-20 15:58 ` E Sabof 1 sibling, 0 replies; 51+ messages in thread From: E Sabof @ 2013-03-15 14:08 UTC (permalink / raw) To: Tassilo Horn; +Cc: 13887 [-- Attachment #1: Type: text/plain, Size: 432 bytes --] 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@gnu.org> wrote: > E Sabof <esabof@gmail.com> writes: > > > Now it works in "emacs -Q", but not with my configuration. > > Do you mind to share your configuration? > > Bye, > Tassilo > [-- Attachment #2: Type: text/html, Size: 925 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-15 13:55 ` Tassilo Horn 2013-03-15 14:08 ` E Sabof @ 2013-03-20 15:58 ` E Sabof 2019-09-26 17:16 ` Lars Ingebrigtsen 1 sibling, 1 reply; 51+ messages in thread From: E Sabof @ 2013-03-20 15:58 UTC (permalink / raw) To: Tassilo Horn; +Cc: 13887 [-- Attachment #1: Type: text/plain, Size: 138 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 194 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-20 15:58 ` E Sabof @ 2019-09-26 17:16 ` Lars Ingebrigtsen 2019-10-14 6:04 ` Lars Ingebrigtsen 0 siblings, 1 reply; 51+ messages in thread From: Lars Ingebrigtsen @ 2019-09-26 17:16 UTC (permalink / raw) To: E Sabof; +Cc: 13887, Stefan Monnier, Tassilo Horn E Sabof <esabof@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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2019-09-26 17:16 ` Lars Ingebrigtsen @ 2019-10-14 6:04 ` Lars Ingebrigtsen 0 siblings, 0 replies; 51+ messages in thread From: Lars Ingebrigtsen @ 2019-10-14 6:04 UTC (permalink / raw) To: E Sabof; +Cc: 13887, Stefan Monnier, Tassilo Horn Lars Ingebrigtsen <larsi@gnus.org> writes: > E Sabof <esabof@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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-14 3:28 ` E Sabof 2013-03-14 3:56 ` E Sabof 2013-03-14 7:24 ` Tassilo Horn @ 2013-03-14 13:26 ` Stefan Monnier 2013-03-14 15:30 ` Tassilo Horn 2 siblings, 1 reply; 51+ messages in thread From: Stefan Monnier @ 2013-03-14 13:26 UTC (permalink / raw) To: E Sabof; +Cc: 13887, Tassilo Horn > + (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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-14 13:26 ` Stefan Monnier @ 2013-03-14 15:30 ` Tassilo Horn 2013-03-14 15:53 ` E Sabof 2013-03-14 16:19 ` Stefan Monnier 0 siblings, 2 replies; 51+ messages in thread From: Tassilo Horn @ 2013-03-14 15:30 UTC (permalink / raw) To: Stefan Monnier; +Cc: 13887, E Sabof Stefan Monnier <monnier@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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-14 15:30 ` Tassilo Horn @ 2013-03-14 15:53 ` E Sabof 2013-03-14 16:19 ` Stefan Monnier 1 sibling, 0 replies; 51+ messages in thread From: E Sabof @ 2013-03-14 15:53 UTC (permalink / raw) To: Tassilo Horn; +Cc: 13887 [-- Attachment #1: Type: text/plain, Size: 1304 bytes --] 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@gnu.org> wrote: > Stefan Monnier <monnier@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 > [-- Attachment #2: Type: text/html, Size: 1900 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-14 15:30 ` Tassilo Horn 2013-03-14 15:53 ` E Sabof @ 2013-03-14 16:19 ` Stefan Monnier 1 sibling, 0 replies; 51+ messages in thread From: Stefan Monnier @ 2013-03-14 16:19 UTC (permalink / raw) To: Tassilo Horn; +Cc: 13887, E Sabof > 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#13887: 24.3; doc-view will render blurry images when image-magick is available 2013-03-06 3:40 bug#13887: 24.3; doc-view will render blurry images when image-magick is available E Sabof 2013-03-06 8:05 ` Tassilo Horn @ 2013-03-06 18:16 ` Stefan Monnier 1 sibling, 0 replies; 51+ messages in thread From: Stefan Monnier @ 2013-03-06 18:16 UTC (permalink / raw) To: E Sabof; +Cc: 13887 > 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
end of thread, other threads:[~2019-10-14 6:04 UTC | newest]
Thread overview: 51+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-03-06 3:40 bug#13887: 24.3; doc-view will render blurry images when image-magick is available E Sabof
2013-03-06 8:05 ` Tassilo Horn
2013-03-06 12:13 ` E Sabof
2013-03-06 13:01 ` Tassilo Horn
2013-03-06 14:19 ` E Sabof
2013-03-06 19:43 ` Tassilo Horn
2013-03-07 15:17 ` E Sabof
2013-03-07 15:55 ` Tassilo Horn
2013-03-07 16:15 ` E Sabof
2013-03-07 22:57 ` E Sabof
2013-03-08 7:57 ` Tassilo Horn
[not found] ` <CAEp6DybMJkagHjRaXPiA_ED_dntOk=5USr+P9DfqRPZ_JrrKww@mail.gmail.com>
2013-03-09 7:25 ` bug#13887: Fwd: " E Sabof
2013-03-09 7:26 ` E Sabof
2013-03-11 9:11 ` Tassilo Horn
2013-03-11 16:57 ` Eli Zaretskii
2013-03-11 18:20 ` Tassilo Horn
2013-03-11 18:45 ` Eli Zaretskii
2013-03-11 20:27 ` Tassilo Horn
2013-03-11 20:59 ` Eli Zaretskii
2013-03-11 22:08 ` E Sabof
2013-03-11 23:41 ` E Sabof
2013-03-12 1:00 ` E Sabof
2013-03-12 8:09 ` Tassilo Horn
2013-03-12 16:50 ` Eli Zaretskii
2013-03-12 18:00 ` Tassilo Horn
2013-03-12 16:52 ` Eli Zaretskii
2013-03-12 17:46 ` E Sabof
2013-03-12 21:11 ` Eli Zaretskii
2013-03-14 3:28 ` E Sabof
2013-03-14 3:56 ` E Sabof
2013-03-14 7:24 ` Tassilo Horn
2013-03-14 15:23 ` E Sabof
2013-03-14 16:48 ` Tassilo Horn
2013-03-14 21:42 ` Tassilo Horn
2013-03-15 1:11 ` E Sabof
2013-03-15 12:52 ` Stefan Monnier
2013-03-15 13:34 ` E Sabof
2013-03-15 17:51 ` Stefan Monnier
2013-03-15 23:26 ` E Sabof
2013-03-16 13:41 ` Stefan Monnier
2013-03-16 23:30 ` E Sabof
2013-03-15 13:55 ` Tassilo Horn
2013-03-15 14:08 ` E Sabof
2013-03-20 15:58 ` E Sabof
2019-09-26 17:16 ` Lars Ingebrigtsen
2019-10-14 6:04 ` Lars Ingebrigtsen
2013-03-14 13:26 ` Stefan Monnier
2013-03-14 15:30 ` Tassilo Horn
2013-03-14 15:53 ` E Sabof
2013-03-14 16:19 ` Stefan Monnier
2013-03-06 18:16 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).