[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] org-mime-htmlize: visual representation (thunderbird)
From: |
Uwe Brauer |
Subject: |
Re: [O] org-mime-htmlize: visual representation (thunderbird) |
Date: |
Wed, 11 Apr 2012 11:44:08 +0200 |
User-agent: |
Gnus/5.110018 (No Gnus v0.18) XEmacs/21.5-b31 (linux) |
>> On Wed, 11 Apr 2012 00:23:54 -0400, Eric Schulte <address@hidden> wrote:
> Uwe Brauer <address@hidden> writes:
>>
>> Uwe
>>
> Hi Uwe,
> Thanks for sending along this helpful review. I've just pushed two
> changes to org-mime so that it now (1) wraps html and images in a
> multipart/related mime structure and (2) marks images as "disposition
> inline" so that they don't show up as attachments.
Hi Eric,
Thanks for your efforts. I have good and bad news. The bad
news is your changes make things worse in Thunderbird, for
reasons I don't understand the header of the resulting
messages reads:
Content-type: text/plain; charset=us-ascii
which is wrong and now png are displayed!
Which brings me to the good news. After I wrote to you I
received a message from the TB developers which emphasised
that, besides the information I have gave you, the main
point is the header, which should be
Content-type: multipart/related; boundary="=-=-="
and the thunderbird developers insist that this is the
RFC 2387 standard.
Gnus actually generate via the mml-generate-mime function
the header
Content-type: multipart/mixed; boundary="=-=-="
which is wrong.
I brought up the issue in the gnus mailing list and the
developers agreed that in the case of a html message with
png the Content-type should follow the RFC standard.
I checked this explicitly: your old code but with a different
mml-generate-mime function generates a message which is
correctly displayed in thunderbird and GMail and Ipod for
that manner.
BTW I don't know how this issue, of the Content-type in the
header, is treated in VM or Wanderlust.
Now the question is how to proceed:
I had the idea of introducing a new variable mml-mime-use-related and wrap it
into the mml-generate-mime code. Then org-mime-htmlize
should set this variable to t, and later a different
function should be added to the mail-send-hook setting the
variable to nil again.
Lars didn't like the idea and came up with a different
implementation. However I don't see how to use it easily. So
I include both solutions and let you decide which fits best
for org-mime-htmlize.
But as it is now you should undo your recent changes because
even with the *new* mml-generate-mime function and your
*new* code the resulting mail is not displayed correctly in
TB.
I have now added lars and the ding mailing list to the CC.
Regards
Uwe
My solution:
,----
| (defvar mml-mime-use-related t
| "*Variable to control whether to use `multipart/mixed' or
`multipart/related'.")
|
| (defun mml-generate-mime ()
| "Generate a MIME message based on the current MML document."
| (let ((cont (mml-parse))
| (mml-multipart-number mml-multipart-number))
| (if (not cont)
| nil
| (mm-with-multibyte-buffer
| (if (and (consp (car cont))
| (= (length cont) 1))
| (mml-generate-mime-1 (car cont))
| (if mml-mime-use-related
| (mml-generate-mime-1 (nconc (list 'multipart '(type .
"related"))
|
cont))
| (mml-generate-mime-1 (nconc (list 'multipart '(type .
"mixed"))
|
cont)))
| (buffer-string))))))
`----
Lars solution
,----
| (defun mml-generate-mime (&optional multipart-type)
| "Generate a MIME message based on the current MML document.
| MULTIPART-TYPE defaults to \"mixed\", but can also
| be \"related\" or \"alternate\"."
| (let ((cont (mml-parse))
| (mml-multipart-number mml-multipart-number)
| (options message-options))
| (if (not cont)
| nil
| (prog1
| (mm-with-multibyte-buffer
| (setq message-options options)
| (if (and (consp (car cont))
| (= (length cont) 1))
| (mml-generate-mime-1 (car cont))
| (mml-generate-mime-1
| (nconc (list 'multipart (cons 'type (or multipart-type "mixed")))
| cont)))
| (setq options message-options)
| (buffer-string))
| (setq message-options options)))))
`----