GNU bug report logs -
#13887
24.3; doc-view will render blurry images when image-magick is available
Previous Next
Reported by: E Sabof <esabof <at> gmail.com>
Date: Wed, 6 Mar 2013 03:42:02 UTC
Severity: normal
Tags: moreinfo
Found in version 24.3
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #92 received at 13887 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
[Message part 2 (text/html, inline)]
This bug report was last modified 5 years and 223 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.