6 May
2019
6 May
'19
9:25 a.m.
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