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:
bindPnueGQg2l.bin
Description: type/subtype
pgpm5GWk8eiO7.pgp
Description: PGP signature
_______________________________________________ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. [email protected] http://lists.gnu.org/mailman/listinfo/emacs-orgmode
