[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[VM] Old bug in "vm-8.2.0b"
From: |
Dr Rainer Woitok |
Subject: |
[VM] Old bug in "vm-8.2.0b" |
Date: |
Tue, 30 Jul 2013 14:43:14 +0200 |
Uday,
there's another bug molesting me since I upgraded from "vm-7.17" or so
to "vm-8.1.1", and this bug is still present in "vm-8.2.0b", too:
Writing a mail and attaching a PDF document to it looks nice, the grey
button line denoting the attachment starts with a cute paper clip to the
left followed by a textual description of the attachment in square
brackets.
After sending off the mail it is stored in my inbox, and there the grey
button line denoting the attachment looks sort of ugly: the cute paper
clip is missing altogether, and the textual description says
"[Unknown/Bad PNG image encoding]PDF: <file name>, [display]".
Back when I was still using "vm-8.1.1" I did a lot of googling and found
several other people having the same complaints. I even found a comment
by you, dated 2011-02-04 and sugesting this having to do with coding
systems. You even offered the following patch then (even though not in
the "git" format used by me below):
--- vm-mime.el.~1~ 2010-04-25 15:34:20.000000000 +0200
+++ vm-mime.el 2013-05-10 11:38:57.775000000 +0200
@@ -3850,11 +3850,13 @@
(save-excursion
(setq work-buffer (vm-make-work-buffer))
(set-buffer work-buffer)
+ (set-buffer-file-coding-system (vm-binary-coding-system))
;; convert just the first page "[0]" and enforce PNG output by "png:"
- (setq success
- (eq 0 (apply 'call-process vm-imagemagick-convert-program
- tempfile t nil
- (append convert-args (list "-[0]" "png:-")))))
+ (let ((coding-system-for-read (vm-binary-coding-system)))
+ (setq success
+ (eq 0 (apply 'call-process vm-imagemagick-convert-program
+ tempfile t nil
+ (append convert-args (list "-[0]" "png:-"))))))
(if success
(progn
(write-region (point-min) (point-max) tempfile nil 0)
To cut a long story short, this patch, even though it was applicable to
"vm-8.1.1", did then not solve the problem (but it didn't hurt either,
so I left it in there). However, instead of trying to transfer this
non-working patch to "vm-8.2.0b" I spent a few days ploughing through
the "vm-8.2.0b" source code and doing a lot of tracing.
In a nutshell, my findings were this:
1. "vm-attach-file" (C-c C-a in mail mode):
- Asks for the file name and calls "vm-attach-object" to do the job
with variable "type" for instance set to "application/octet-stream"
- Only when running under XEmacs "vm-attach-object" calls
(vm-mime-set-image-stamp-for-type extent type)
to insert the thumbnail into the extent.
- And, as mentioned above, it works.
2. "vm-mime-display-button-image" (used when reading mail):
- First calls "vm-mime-frob-image-xxxx" which in turn calls several
other functions to insert a PNG into the extent. For some reason
this fails, leaving the "[Unknown/Bad PNG image encoding]" message
in the extent. One other essential thing this function does, how-
ever, is to set the disposition of the layout to "inline". If this
is not done, later middle-clicking the button will fail.
- Later "vm-mime-display-button-image" calls "vm-mime-set-image-
stamp-for-type" (the function also used by "vm-attach-object") to
do its magic, but this function cannot repair the already corrupted
button.
- So apparently somehow function "vm-mime-display-button-image" tries
to insert two thumbnails into the button.
My first attempt therefore was to simply comment out the call to "vm-
mime-frob-image-xxxx" within function "vm-mime-display-button-image".
This displayed a neat button which could however not be middle clicked.
Further tracing then revealed the necessity of the above mentioned
"inline" disposition.
So finally I came up with the following patch which worked at least for
me:
--- vm-mime.el.orig 2011-12-28 00:19:28.000000000 +0200
+++ vm-mime.el 2013-07-30 13:20:05.554100000 +0200
@@ -4559,6 +4559,14 @@
tempfile)
(vm-register-folder-garbage-files (list tempfile))
;; display a thumbnail over the fake extent
+ ;; (do that at most for GNU Emacs (if it should work there),
+ ;; otherwise skip function `vm-mime-frob-image-xxxx' entirely
+ ;; here, because for XEmacs the thumbnail will later again be
+ ;; inserted by function `vm-mime-set-image-stamp-for-type'.
+ ;; However, `vm-mime-frob-image-xxxx' marks the layout as being
+ ;; "inline", which is essential and which therefore is the only
+ ;; thing we do here for XEmacs -- R Woitok 2013-07-30)
+ (if vm-xemacs-p (vm-set-mm-layout-disposition layout '("inline"))
(let ((vm-mime-internal-content-types '("image"))
(vm-mime-internal-content-type-exceptions nil)
(vm-mime-auto-displayed-content-types '("image"))
@@ -4566,7 +4574,7 @@
(vm-mime-use-image-strips nil))
(vm-mime-frob-image-xxxx thumb-extent
"-thumbnail"
- vm-mime-thumbnail-max-geometry))
+ vm-mime-thumbnail-max-geometry)))
;; extract image data, don't need the image itself!
;; if the display was not successful, glyph will be nil
(setq glyph (if vm-xemacs-p
Please run your test suite against this patch, ponder over it using your
insider knowledge, and then tell me what you think. I have detailed
trace output available, if you are interested, but I hesitate to post
this to the list.
Sincerely
Rainer
----------------------------------------------------------------------
| Rainer M Woitok | Phone : (+49 60 93) 487 95 95 |
| Kolpingstraße 3 | Mobile: (+49 172) 813 6 831 |
| D-63846 Laufach | Mail : address@hidden |
| Germany | |
----------------------------------------------------------------------
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [VM] Old bug in "vm-8.2.0b",
Dr Rainer Woitok <=