On Sun, May 05, 2019 at 10:07:52PM -0400, Gene Heskett wrote: > it seems > to me a mime break and a new treatment for the binary data being loaded > could be written, Of course you can add multiple attachments and alternate them: <text attachment> <image attachment> <text attachment> <image attachment> <text attachment> <image attachment> and I believe that's what Apple Mail does (but don't have a Mac to try it myself and see). http://forums.mozillazine.org/viewtopic.php?f=39&t=687895 You could try that and see which email clients will render them all inline. I think Thunderbird may be capable of doing that, but I expect most people will just see the first text part followed by a list of attachments to click on. When you talk about "a new treatment ... can be written" I'm not sure what you mean. I presume you aren't expecting to write a patch for everyone's email client (of which there are dozens) to support this. > the mimetype already exists and has for 2 decades and > it would never have to be in the same room as html. HTML emails use precisely the same MIME system that is also used for text, images and any other format. If it wasn't for MIME, we couldn't have HTML emails. Gene, we get it that you don't like HTML emails, but what you are trying to do is precisely the problem that HTML was designed to solve: it is a rich text presentation format capable of displaying mixed text and inline images. And it is a format which, like it or not, is supported to some degree by the vast bulk of email clients. Even if you found a non-HTML solution, it doesn't do you any good if nobody else's mail clients supports that format. > IMO m$ and html have wrecked email by convincing todays generation that > html, with its 5x multiplication of message size, is the only game in > town. Most mail clients generate crappy html, but that's a "quality of implementation" problem, not a problem with the technology itself. For instance, I just sent myself a seven line HTML message from Kmail, and here are the sizes as reported by mutt: - plain text version: 0.1K - HTML version: 0.3K For the record, here's the HTML part: <html><head><meta name="qrichtext" content="1" /></head><body style="font-size:10pt;font-family:Liberation Mono"> <p><span style="font-weight:600">Testing.</span></p> <p></p> <p>Testing.</p> <p></p> <p></p> <p>-- </p> <p>Steven D'Aprano</p> <p></p> </body></html> You don't get much tighter HTML than that. Of course there's a bit of overhead, but any rich presentation format will have some overhead. If the content of my test mail was more realistic, the overhead would be a correspondingly smaller percentage of the total size. Realistically, you're probably sending hundreds of kilobytes, maybe even megabytes, worth of images in a single email. If the HTML adds another 1 KB or even 10 KB, why do you care? > It should not be. A mime boundary break is rarely over 250 chars, > adding maybe 500 bytes to ID to the mail agent what the next block of > binary is. But a couple of 250 byte mime boundary's can surround a 4 > megabyte jpeg straight out of my camera, very high def, and an expansion > of the total message size for the boundary strings isn't even pocket > change compared to the cost of html for the same thing. Using HTML mail shouldn't expand the size of JPEG attachments any more than they would be expanded as attachments. If the HTML links to the attached image, then the images are precisely attachments, and there's no difference in size. If the HTML embeds the image data in the file (which may not be supported by all clients!) it will probably use Base64 encoding, which is the exact same encoding your email client uses when attaching binary files. So again, there won't be any increase in size over a regular attachment, aside from a handful of characters for the HTML tag itself. The bottom line is: - while HTML emails are abused and misused in many ways, they are a well-supported standard that allows precisely the result you are after. - but Kmail doesn't appear to support this particular feature. -- Steven