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

Previous Next

Full log

View this message in rfc822 format

From: Tassilo Horn <tsdh <at> gnu.org>
To: E Sabof <esabof <at> gmail.com>
Cc: 13887 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#13887: 24.3; doc-view will render blurry images when image-magick is available
Date: Tue, 12 Mar 2013 09:09:54 +0100

Eli Zaretskii writes:

> What is the "right" overlay?

There should be exactly one overlay in the doc-view buffer whose window
property is the currently selected window, and that window has this
overlay accociated in `image-mode-winprops-alist'.

E Sabof <esabof <at> gmail.com> writes:

> Further evidence suggests that the "t taking precedence" version is
> wrong.  It's more probable the the precedence is determined by the
> order of overlays in some C data-structure.

I think the buffer-local value of `image-mode-winprops-alist' should
always look like:

--8<---------------cut here---------------start------------->8---
((#<window 0x846c030 on IncPat.pdf>
	   (overlay . #<overlay from 1 to 756769 in IncPat.pdf>)
	   (image image :type imagemagick :file "/tmp/docview1000/IncPat.pdf-982c2eddc6c753dafecbffecb17d5993/page-12.png" :width 685)
	   (info .
		 #("Page 12 of 13.\n" 0 14
		   (face bold)))
	   (page . 12)
	   (slice))
 (t
  (page . 1)
  (overlay . #<overlay in no buffer>)))
--8<---------------cut here---------------end--------------->8---

That is, there's one entry for any window that shows this doc-view
buffer, plus one t-entry with a deleted overlay.  The order of entries
is by recency of window activations (or creations?), I think.  t is
always the last.

When `doc-view-new-window-function' is called for the very first time
for a new doc-view buffer (i.e., you opened a new document), (car
winprops) is t.  I that case, a new overlay is created, doc-view and
window properties are added (both t), it's associated in winprops (the
t-entry), and then it's deleted so that its not shown (because at this
point in time the image to be shown might not exist).  This entry acts
as default if there are no other entries.

Thereafter, it's immediately called again with a concrete window in (car
winprops).  Don't ask me from where.  I'm edebugging
`doc-view-new-window-function', but this call doesn't drop me in the
edebugger as the previous one did.  I just see the message

  New window #<window 0x7751d70 on foo.pdf> for buf foo.pdf

in the echo area.

With the second and any subsequent call of
`doc-view-new-window-function' for a given doc-view buffer, the overlay
of the top-entry in `image-mode-winprops-alist' is copied.  That way,
the new window shows the same page with the same zoom level/slice as the
most recent other window showing the document.

Yesterday, when things were messed up, I know that
`image-mode-winprops-alist' looked like that:

--8<---------------cut here---------------start------------->8---
((#<window 0x846c030 on IncPat.pdf>
	   ...)
 (t
  (page . 1)
  (overlay . #<overlay from 1 to 756769 in IncPat.pdf>)))
--8<---------------cut here---------------end--------------->8---

That is, the t-entry had an overlay that hasn't been deleted.  I don't
know how I could reach that state (I just quickly switched pages,
zoomed, sliced, split window), but that seems wrong and might be the
culprit because some other window in might already use that.

Bye,
Tassilo

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.