Re: [Evolution] HTML mail

[Benjamin Kahn <xkahn zoned net>]

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);
        else

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.