Re: [Evolution] HTML mail

[Not Zed <notzed ximian com>]

Nup, that file doesn't exist, and it was totally rewritten anyway.

On Sat, 2004-05-22 at 21:52 -0400, Benjamin Kahn wrote:
> 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.

Michael Zucchi <notzed ximian com> Ximian Evolution and Free Software Developer

Novell, Inc.