Hi David, David Maus <dm...@ictsoc.de> writes:
[...] > 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. > Ah thanks, I will look to see if there is such a function distributed with the core Emacs, else a simple alist should suffice. > > 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. > I should have been clearer here. I *am* using the multipart/alternative appropriately. When a chunk of org-mode text is converted to html I am adding a single multipart/alternative block with two alternatives, both the plain org-mode text, and the html, so that users like me who prefer to see plain text can do so, and users of web clients like gmail can see nice markup. > > 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: And the limits of user email to discuss email have been reached :) gnus seems to have mangled some of the following examples, but I have tried to flesh out the 'semi portions org-mail-htmlize given what I was able to salvage (see the latest commit). I still can't figure out the SEMI multipart/alternative syntax. Please let me know if you have the syntax at hand, feel like submitting a patch, or you would like commit permission to the git repo. Much Thanks! -- Eric _______________________________________________ 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
