viewmail-info
[Top][All Lists]
Advanced

[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                        |                                     |
 ----------------------------------------------------------------------



reply via email to

[Prev in Thread] Current Thread [Next in Thread]