Hi,
plain html))
('semi "?")
('vm "?"))
#+end_srceverything 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.
<<attachment: mail2517Uwd_bec399e15ff6f585494f84227a582a8056aca5a5.png>>
<<attachment: mail2517Uwd_da7d4c60345e5ae9c5d477dbb9995ea627d66593.png>>
David Maus <dm...@ictsoc.de> writes: > Okay, took a look on the specs and attached is a memo on how an > implementation of org to MIME could be done. The MIME delimiters of > SEMI and mml are quite similar so there's already a generic function > that creates representation of a MIME message for both. > > I've published this memo on Worg, too, occupying some space in > > http://orgmode.org/worg/org-devel.php > I took a look at this page, but it wasn't entirely clear to me what the SEMI markup language should look like. As mentioned above, for now I've gone with `case' statements for each mime library, rather than an alist of format strings -- in the off chance that different libraries could require information in a different order. > > 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. > > Best > -- David > Cheers -- Eric > > -- > OpenPGP... 0x99ADB83B5A4478E6 > Jabber.... dmj...@jabber.org > Email..... dm...@ictsoc.de > > > Author: David Maus <dm...@ictsoc.de> > Date: 2010-03-25 21:56:50 CET > > > Table of Contents > ================= > 1 Representing a MIME internet message > 2 MIME delimiters of SEMI and mml > 3 Generic function > 4 Open questions > 4.1 How to handle charset information? > 4.2 How to attach files? > 5 Quotes from the specs > 5.1 MIME multipart: Notion of structured, related body parts > 5.2 MIME multipart: order of entities inside a multipart > > > 1 Representing a MIME internet message > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > A MIME internet message consists of one or more MIME entities. Each > MIME entity is of a distinct type and subtype, has a body and > optional MIME headers related to it's content. > > A MIME entity is represented as a list: > > (TYPE SUBTYPE BODY CONT-HEAD) > > TYPE: Symbol of MIME media type (e.g. text, video, audio). > > SUBTYPE: Symbol of MIME media subtype (e.g. plain, html). > > BODY: String with entity body -or- list of other MIME entities. > > CONT-HEAD: List of cons with content related MIME header > fields. The name of the header field without the > prefix "Content-" is car, the value cdr. > > Example: > > > '(text html "<h1>Headline</h1>" ((disposition . inline))) > > For messages of type multipart the body consists of a list of one > or more MIME entities. > > '(multipart alternative > '((text plain "* Headline") > (text html "<h1>headline</h1>"))) > > 2 MIME delimiters of SEMI and mml > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > The MIME delimiters are defined in an association list with a > symbol of the library's name as key and delimiter format strings as > values. For each library there are three formatstrings. > > (SYMBOL DELIM-SINGLE DELIM-SINGLE-CONT DELIM-MULTI) > > DELIM-SINGLE: Denoting a single MIME entity. > > Strings are passed in this order: > > 1. type > > 2. subtype > > 3. content header > > 4. body > > DELIM-SINGLE-CONT: Format of content header strings. > > Strings are passed in this order: > > 1. header field name > > 2. header field value > > DELIM-MULTI: Enclosing parts of a multipart entity. > > Strings are passed in this order: > > 1. subtype > > 2. body > > 3. subtype > > > (setq org-mail-htmlize-mime-delimiter-alist > '((semi "\n- -[%s/%s%s]\n%s" "\ncontent-%s: %s" "\n- -<<%s>>-{\n%s\n- > -}-<<%s>>") > (mml "\n<#part type=\"%s/%s\"%s>\n%s" " %s=\"%s\"" "\n<#multipart > type=\"%s\">\n%s\n<#/multipart>"))) > > 3 Generic function > ~~~~~~~~~~~~~~~~~~~ > > This generic function returns a string representation with MIME > delimiters depending on the variable =org-mail-htmlize-mime-lib=. > > > (setq org-mail-htmlize-mime-lib 'semi) > > > (defun org-mail-htmlize-mime-entity (type subtype body > &optional cont-head) > "Return string representation of MIME entity. > > TYPE is the type of entity body. > SUBTYPE is the subtype of body. > BODY is the body of the entity. Either a string with the body > content or a list with one ore more MIME entities. > Optional argument CONT-HEAD is a list of cons with content > specific headers, name in car and value in cdr." > (let ((delimlst (assoc org-mail-htmlize-mime-lib > org-mail-htmlize-mime-delimiter-alist))) > (if (eq type 'multipart) > (format (nth 3 delimlst) subtype > (mapconcat '(lambda (b) > (apply 'org-mail-htmlize-mime-entity > (car b) (cadr b) (cddr b))) > body "") > subtype) > (format (nth 1 delimlst) > type subtype > (mapconcat '(lambda (h) > (format (nth 2 delimlst) (car h) (cdr h))) > cont-head "") > body)))) > > 4 Open questions > ~~~~~~~~~~~~~~~~~ > > 4.1 How to handle charset information? > ======================================= > > 4.2 How to attach files? > ========================= > > The generic function expects BODY either be a string or a list. > Attaching binary file (image, etc.) requires to encode it so the > message will pass the message system. So we /might/ use kind of a > encoder (e.g. base64) on our own. > > Or, what seems a cleaner solution: Use attachment function of the > respective MIME mode. To achive this: Introduce third possibility > for BODY: A cons with the filename in car and symbol of the > function in cdr. > > (FILENAME . FUNCTION) > > > '(image jpeg ("/path/to/image" . org-mail-htmlize-add-attachment)) > > The function =org-mail-htmlize-add-attachment= is called with file > name as argument and calls the appropriate function depending on > =org-mail-htmlize-mime-lib= and returns a string > > - with the encoded body > > -or- > > - the complete MIME entity > > Side effect: The user might be prompted for attachment settings > (e.g. encoding). But, on the other hand: We delegate the job of > creating the attachment to the library that is responsible for > mime. > > 5 Quotes from the specs > ~~~~~~~~~~~~~~~~~~~~~~~~ > > 5.1 MIME multipart: Notion of structured, related body parts > ============================================================= > > - [RFC2046, 5.1.1] > > ORG-BLOCKQUOTE-START > NOTE: Conspicuously missing from the "multipart" type is a notion of > structured, related body parts. It is recommended that those wishing > to provide more structured or integrated multipart messaging > facilities should define subtypes of multipart that are syntactically > identical but define relationships between the various parts. For > example, subtypes of multipart could be defined that include a > distinguished part which in turn is used to specify the relationships > between the other parts, probably referring to them by their > Content-ID field. Old implementations will not recognize the new > subtype if this approach is used, but will treat it as > multipart/mixed and will thus be able to show the user the parts that > are recognized. > ORG-BLOCKQUOTE-END > > [RFC2046, 5.1.1]: http://tools.ietf.org/html/rfc2046.html#section-5.1.1 > > 5.2 MIME multipart: order of entities inside a multipart > ========================================================= > > - [RFC2046, 5.1.3] > > ORG-BLOCKQUOTE-START > 5.1.3. Mixed Subtype > > The "mixed" subtype of "multipart" is intended for use when the body > parts are independent and need to be bundled in a particular order. > Any "multipart" subtypes that an implementation does not recognize > must be treated as being of subtype "mixed". > > ORG-BLOCKQUOTE-END > > - [RFC2046, 5.1.4] > > ORG-BLOCKQUOTE-START > 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. > ORG-BLOCKQUOTE-END > > ORG-BLOCKQUOTE-START > 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. > ORG-BLOCKQUOTE-END > > [RFC2046, 5.1.3]: http://tools.ietf.org/html/rfc2046.html#section-5.1.3 > [RFC2046, 5.1.4]: http://tools.ietf.org/html/rfc2046.html#section-5.1.4
_______________________________________________ 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
