> _If_ you're running emacs/X, and if you have emacs-w3m, and if you have
> inline images enabled, you can _see_ the image. Also vm-mime-save-all-
> attachments will allow you to save it. But you can't get to just one
> individual mime attachment (like if you just want to launch an external
> image viewer without having to save all the attachments, go to the shell
> or a file manager and manually start the image viewer in whatever your
> favorite way is).
I think what is happening is that people are doing drag-and-drop into the
html editor instead of "attaching" graphics images. The html editors assume
that they want to place the images in the middle of the text rather than
attaching them. That is why we are seeing increasing use of
multipart/related.
Treating multipart/related as multipart/mixed will solve these problems for
you.
But, that is not what multipart/related was designed for. Quoting RFC 2387:
The Multipart/Related media type is intended for compound objects
consisting of several inter-related body parts. For a
Multipart/Related object, proper display cannot be achieved by
individually displaying the constituent body parts.
For genuine multipart/related content, I have now found a nice generic
solution. Commiting it soon.
John Hein writes:
> _If_ you're running emacs/X, and if you have emacs-w3m, and if you have
> inline images enabled, you can _see_ the image. Also vm-mime-save-all-
> attachments will allow you to save it. But you can't get to just one
> individual mime attachment (like if you just want to launch an external
> image viewer without having to save all the attachments, go to the shell
> or a file manager and manually start the image viewer in whatever your
> favorite way is).
I think what is happening is that people are doing drag-and-drop into the
html editor instead of "attaching" graphics images. The html editors assume
that they want to place the images in the middle of the text rather than
attaching them. That is why we are seeing increasing use of
multipart/related.
Treating multipart/related as multipart/mixed will solve these problems for
you.
But, that is not what multipart/related was designed for. Quoting RFC 2387:
The Multipart/Related media type is intended for compound objects Related object, proper display cannot be achieved by
consisting of several inter-related body parts. For a
Multipart/
individually displaying the constituent body parts.
For genuine multipart/related content, I have now found a nice generic
solution. Commiting it soon.
Cheers,
Uday