From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.bugs 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 Message-ID: <877gldyr71.fsf@thinkpad.tsdh.de> References: <8762143co6.fsf@thinkpad.tsdh.de> <877glkgvqj.fsf@thinkpad.tsdh.de> <87txonw6ev.fsf@thinkpad.tsdh.de> <87sj46493q.fsf@thinkpad.tsdh.de> <877gle1etb.fsf@thinkpad.tsdh.de> <838v5tx4av.fsf@gnu.org> <87txohx0g0.fsf@thinkpad.tsdh.de> <831ubllqr0.fsf@gnu.org> <87zjy9vg0r.fsf@thinkpad.tsdh.de> <83y5dtk606.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1363075871 26700 80.91.229.3 (12 Mar 2013 08:11:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 12 Mar 2013 08:11:11 +0000 (UTC) Cc: 13887@debbugs.gnu.org To: E Sabof Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Mar 12 09:11:35 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UFKJ5-00023m-Be for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Mar 2013 09:11:35 +0100 Original-Received: from localhost ([::1]:43228 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFKIj-0001wb-0A for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Mar 2013 04:11:13 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:47931) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFKId-0001wI-BY for bug-gnu-emacs@gnu.org; Tue, 12 Mar 2013 04:11:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UFKIZ-0001sg-JP for bug-gnu-emacs@gnu.org; Tue, 12 Mar 2013 04:11:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43529) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFKIZ-0001sc-Ge for bug-gnu-emacs@gnu.org; Tue, 12 Mar 2013 04:11:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UFKJV-000326-QM for bug-gnu-emacs@gnu.org; Tue, 12 Mar 2013 04:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Tassilo Horn Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Mar 2013 08:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13887 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13887-submit@debbugs.gnu.org id=B13887.136307586211573 (code B ref 13887); Tue, 12 Mar 2013 08:12:01 +0000 Original-Received: (at 13887) by debbugs.gnu.org; 12 Mar 2013 08:11:02 +0000 Original-Received: from localhost ([127.0.0.1]:47638 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UFKIW-00030T-4T for submit@debbugs.gnu.org; Tue, 12 Mar 2013 04:11:00 -0400 Original-Received: from deliver.uni-koblenz.de ([141.26.64.15]:52357) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UFKIR-00030J-Oz for 13887@debbugs.gnu.org; Tue, 12 Mar 2013 04:10:58 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by deliver.uni-koblenz.de (Postfix) with ESMTP id 267A91A89F7; Tue, 12 Mar 2013 09:09:56 +0100 (CET) X-Virus-Scanned: amavisd-new at uni-koblenz.de Original-Received: from deliver.uni-koblenz.de ([127.0.0.1]) by localhost (deliver.uni-koblenz.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njl30FF79tQ0; Tue, 12 Mar 2013 09:09:55 +0100 (CET) X-CHKRCPT: Envelopesender noch tsdh@gnu.org Original-Received: from thinkpad.tsdh.de (tsdh.uni-koblenz.de [141.26.67.142]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTPSA id 987631A89FC; Tue, 12 Mar 2013 09:09:55 +0100 (CET) In-Reply-To: (E. Sabof's message of "Tue, 12 Mar 2013 01:00:11 +0000") User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:72365 Archived-At: 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 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--- ((# (overlay . #) (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 . #))) --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 # 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--- ((# ...) (t (page . 1) (overlay . #))) --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