From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Maus Subject: Re: using orgmode to send html mail? Date: Fri, 26 Mar 2010 17:04:37 +0100 Message-ID: <87zl1vf4ru.wl%dmaus@ictsoc.de> References: <878w9krtyn.wl%dmaus@ictsoc.de> <871vfa24qo.fsf@gmail.com> <87pr2uww2d.fsf@columbia.edu> <87tys5zrwm.fsf@gmail.com> <87sk7pzk02.fsf@stats.ox.ac.uk> <87tys5r3q6.fsf@gmail.com> <87ocid7cuj.wl%dmaus@ictsoc.de> <874ok5qxp9.fsf@gmail.com> <87vdckksnj.wl%dmaus@ictsoc.de> <874ok33zje.fsf@gmail.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/mixed; boundary="===============0919666341==" Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NvC1h-0002N0-Md for emacs-orgmode@gnu.org; Fri, 26 Mar 2010 12:04:49 -0400 Received: from [140.186.70.92] (port=56340 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NvC1g-0002Lq-6C for emacs-orgmode@gnu.org; Fri, 26 Mar 2010 12:04:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NvC1d-0006Sy-IH for emacs-orgmode@gnu.org; Fri, 26 Mar 2010 12:04:47 -0400 Received: from mysql1.xlhost.de ([213.202.242.106]:39764) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NvC1c-0006Sf-0h for emacs-orgmode@gnu.org; Fri, 26 Mar 2010 12:04:44 -0400 In-Reply-To: <874ok33zje.fsf@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Eric Schulte Cc: Dan Davison , emacs-orgmode@gnu.org --===============0919666341== Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Fri_Mar_26_17:04:37_2010-1"; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit --pgp-sign-Multipart_Fri_Mar_26_17:04:37_2010-1 Content-Type: multipart/mixed; boundary="Multipart_Fri_Mar_26_17:04:37_2010-1" --Multipart_Fri_Mar_26_17:04:37_2010-1 Content-Type: text/plain; charset=US-ASCII Eric Schulte wrote: >So I believe inline LaTeX images are working in gnus, see here >[cid] and immediately below >[cid] >This turned out to be fairly easy, and didn't require any encoding or >explicit mime function calls. >I've also re-structured the code so that it should be easy to apply the >appropriate mime markup for WL and VM. There are now two mime-library >dependent functions `org-mail-file' and `org-mail-multipart' each of >which contains a `case' block for library-specific behavior, e.g. >(case org-mail-mime-library > ('mml (format (concat "<#multipart type=alternative><#part type=text/plain>" > "%s<#part type=text/html>%s<#/multipart>\n") > plain html)) > ('semi "?") > ('vm "?")) >everything is available at http://github.com/eschulte/org-html-mail >I'd love to hear feedback, suggestions, or expansion of the missing WL >and VM portions of the two functions mentioned above. Two remarks: 1st/ ,---- | (add-to-list 'html-images | (org-mail-file (concat "image/" ext) path id)) `---- Using the file extension as subtype is not in compliance with the specs. For instance the MIME type of "filename.jpg" is image/jpeg, not image/jpg (cf. RFC 2046, 4.2). What you need is kind of a function or software that returns MIME type of a file name. In SEMI it's `mime-find-file-type'. Or maybe don't set the type, maybe mml will pick a type for you. 2nd/ The usage of multipart/alternative is not in compliance with the specs, too. There it reads: RFC2046, 5.1.4 ,---- | 5.1.4. Alternative Subtype | | The "multipart/alternative" type is syntactically identical to | "multipart/mixed", but the semantics are different. In particular, | each of the body parts is an "alternative" version of the same | information. | | Systems should recognize that the content of the various parts are | interchangeable. Systems should choose the "best" type based on the | local environment and references, in some cases even through user | interaction. As with "multipart/mixed", the order of body parts is | significant. In this case, the alternatives appear in an order of | increasing faithfulness to the original content. In general, the best | choice is the LAST part of a type supported by the recipient system's | local environment. | | In general, user agents that compose "multipart/alternative" entities | must place the body parts in increasing order of preference, that is, | with the preferred format last. For fancy text, the sending user agent | should put the plainest format first and the richest format | last. Receiving user agents should pick and display the last format | they are capable of displaying. In the case where one of the | alternatives is itself of type "multipart" and contains unrecognized | sub-parts, the user agent may choose either to show that alternative, | an earlier alternative, or both. `---- So if you attach *only a part* of the plain text message body, you should not use multipart/alternative: Because 1. a part of a message is not "an 'alternative' version of the same information." 2. if recipients user agent prefers html messages it will display only the html'ized part. Better use multipart/alternative for plain text and html of the entire body and additional multipart/mixed for snippets. If the html output should contain images, than maybe use a multipart/mixed with type text/html beneath the text/plain, so the receiving MUA might pick it up when prefering html. With regards to SEMI the delimiters are (inserted a space between two succeeding dashes): - single entity: --Multipart_Fri_Mar_26_17:04:37_2010-1 Content-Type: type/subtype;parameters Content-Transfer-Encoding: encoding - mulipart entity - -<>-{BODY- -}-<> Real live example for a single entity: --[[application/octet-stream; type=patch Content-Disposition: attachment; filename="fix-docstring-author-info.diff"][base64]] > > > > The tasks at hand would be: find the functions that attach a file in > > mime-edit-mode and mml-mode and look who they can be utilized. > > > I think that the mime markup libraries should handle attaching image > (including any encoding issues). For example in gnus with mml only the > path to the image need be supplied. And hopefully mml inserts correct information on character encoding for non-latin textual content, too. SEMI does. HTH -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber.... dmjena@jabber.org Email..... dmaus@ictsoc.de --Multipart_Fri_Mar_26_17:04:37_2010-1-- --pgp-sign-Multipart_Fri_Mar_26_17:04:37_2010-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EABEIAAYFAkus2xUACgkQma24O1pEeObdLwD/eGfiIdlJL3sMlRtQLA/Tt0x2 DUnRFyOO02mPK8fsv+YBAOc+81xJQY+uJ68ioScbssv0AW56khlesDCSTyPOuG16 =9Onb -----END PGP SIGNATURE----- --pgp-sign-Multipart_Fri_Mar_26_17:04:37_2010-1-- --===============0919666341== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode --===============0919666341==--