Re: [Evolution] HTML mail

I wrote a patch to do this once, but it was written for a /very/ old
version of Evolution.  It probably doesn't work and probably never
did...  :)  Anyway, here it is:

--- mail/mail-format.c  Thu Nov  8 15:39:36 2001
+++ mail/mail-format.c.orig     Sat Nov 10 16:55:31 2001
@@ -1971,7 +1971,7 @@
        multipart = CAMEL_MULTIPART (wrapper);
-       mime_part = find_preferred_alternative (multipart, FALSE);
+       mime_part = find_preferred_alternative (multipart, TRUE);
        if (mime_part)
                return format_mime_part (mime_part, md);

I'd be surprised if it even still applies.

On Sun, 2004-05-23 at 08:59 +0800, Not Zed wrote:
On Sat, 2004-05-22 at 21:03 +0200, Eric Schaefer wrote: 
On Sat, 2004-05-22 at 20:05, Andre Klapper wrote:
if i remember correctly, this has not been implemented since the rfc
says that a message which has been sent both as html and plaintext
should be displayed in html (correct me if i'm wrong).
This is not quite correct. 
So why would you want to send the plaintext along with the html anyways?
Pretty simple, because not all clients can display html properly.
Read the relevent sections of rfc 2046 if you need more detailed
justification.  Its to do with interoperability and open extensibility
of the format. 
I dont think there is a RFC that deals with overriding user preferences
for mail display (mail encoding is another chapter). If I want all my
mail displayed as rot39 encoded plaintext, blue text on red background,
the MUA ought to display it that way.
I would disagree.  Since that would be a pointless feature to add; it
would even be useless to you since it isn't a standard representation
of a typical human language.

Back to the topic, "multipart/alternative" is pretty simple, it
provides the ability to send alternate and richer forms of email in
ways that can still be ready by older or less featureful clients.  The
standard says 'display the last part you know how to handle', and for
senders 'send the data in order from most to least information lost'.

So we take the simplest approach - we follow the spec.  Evolution is a
html emailer, it runs in a grpaphical environment, doing some
artificial feature limitation as a user preferences doesn't have a lot
of use.  And what are we supposed to do if we only get text/html with
no plain alternative?  Just display it as an attachment?

Its not even that hard to do, probably a few lines of commented out
code to make out evo is too dumb to know about text/html, i think,
although it always tries to fallback for text/ types so it might need
more code.

But, it just doesn't seem that useful.

If someone had really felt that strongly about it, they might've
written a patch, but nobody has.

Michael Zucchi
<notzed ximian com>

Ximian Evolution and
Free Software Developer

Novell, Inc.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]