unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Tassilo Horn <tsdh@gnu.org>
To: E Sabof <esabof@gmail.com>
Cc: 13887@debbugs.gnu.org
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	[thread overview]
Message-ID: <877gldyr71.fsf@thinkpad.tsdh.de> (raw)
In-Reply-To: <CAEp6DyYcnEXVwcnMz3ERXktm5x90nZ5M+Lc9yhRRuJZQjnLEKA@mail.gmail.com> (E. Sabof's message of "Tue, 12 Mar 2013 01:00:11 +0000")

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





  reply	other threads:[~2013-03-12  8:09 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877gldyr71.fsf@thinkpad.tsdh.de \
    --to=tsdh@gnu.org \
    --cc=13887@debbugs.gnu.org \
    --cc=esabof@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).