bug#13887: 24.3; doc-view will render blurry images when image-magick is available

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[E Sabof]

[-- 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 --]

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Tassilo Horn]

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

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[E Sabof]

[-- 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 --]

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Tassilo Horn]

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

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[E Sabof]

[-- 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 --]

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Stefan Monnier]

> 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

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Tassilo Horn]

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

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[E Sabof]

[-- 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 --]

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Tassilo Horn]

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

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[E Sabof]

[-- 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 --]

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[E Sabof]

[-- 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 --]

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Tassilo Horn]

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

bug#13887: Fwd: bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[E Sabof]

[-- 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 --]

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[E Sabof]

[-- 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 --]

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Tassilo Horn]

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

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Eli Zaretskii]

> 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.

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Tassilo Horn]

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

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Eli Zaretskii]

> 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?

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Tassilo Horn]

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

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Eli Zaretskii]

> 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?

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[E Sabof]

[-- 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 --]

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[E Sabof]

[-- 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 --]

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[E Sabof]

[-- 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 --]

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Tassilo Horn]

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

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Eli Zaretskii]

> 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?

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Eli Zaretskii]

> 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.

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[E Sabof]

[-- 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 --]

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Tassilo Horn]

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

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Eli Zaretskii]

> 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.

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[E Sabof]

[-- 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 --]

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[E Sabof]

[-- 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 --]

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Tassilo Horn]

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

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Stefan Monnier]

> +        (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

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[E Sabof]

[-- 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 --]

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Tassilo Horn]

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

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[E Sabof]

[-- 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 --]

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Stefan Monnier]

> 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

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Tassilo Horn]

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

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Tassilo Horn]

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

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[E Sabof]

[-- 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 --]

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Stefan Monnier]

> 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

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[E Sabof]

[-- 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 --]

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Tassilo Horn]

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

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[E Sabof]

[-- 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 --]

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Stefan Monnier]

> 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

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[E Sabof]

[-- 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 --]

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Stefan Monnier]

> Should I try to patch it? Without "window t" image-mode would be more
> predictable.

I don't know.


        Stefan

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[E Sabof]

[-- 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 --]

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[E Sabof]

[-- 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 --]

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Lars Ingebrigtsen]

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

bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Lars Ingebrigtsen]

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