Using 2000-02-28 build on Windows NT 1. Compose a mail message using the HTML compose window 2. Before sending, use Options | Format | Plain text to set the outgoing content-type 3. Send the message 4. Display the message in the Sent folder Expected: message to be displayed in fixed width font, since the content-type is text/plain. Actual: message is displayed in variable width font, as though content-type had been text/html.

Phil, is the content type precisely "text/plain; format=flowed"? It yes, it is completely correct to display flowed parts in a variable font. Not sure, what happens for preformatted parts (compare description of bug #29369). CCing Daniel for that. Changing SUMMARY.

> is the content type precisely "text/plain; format=flowed"? Yes, of course. > It yes, it is completely correct to display flowed parts in a variable font. Yuck. Why? I'd rather use a fixed width font, and soft-wrap the lines. I don't see why soft-wrapping implies variable width fonts. In addition, we use HTML-style quoting for these messages, and there's no way that's right.

> I don't see why soft-wrapping implies variable width fonts. Soft-wrapping implies, that usage of variable width fonts is possible (or am I wrong here?). If possible, variable width fonts should be used, because they are easier to read. If you /prefer/ fixed width fonts for plain text mails (of all sorts), you can set the x-unicode serif font pref to Courier. > In addition, we use HTML-style quoting for these messages, and there's no > way that's right. Why? For format=flowed, we know for sure, that this is a quote, because the sender marks it as such, so there's no ambiguity. Inserting "> "s creates problems for nested quotes. You can't remove them anymore at send to mark the quote as such in format=flowed, and you can't let the quote flow anymore, which make one of the major advantages of format=flowed (solving problems with nested quotes) useless. Enclosing the quote in a "blockquote"-tag also makes formatting per CSS possible (assuming, that we will have a Mailnews-stylesheet in the future).

I don't see this. The message is displayed according to the mail.fixed_width_messages pref as it should be. At least a bug against me before christmas said that it should respect that setting. Could you give an example of a mail that has this problem. (Technically, the text is internally wrapped in <tt> when being displayed in a fixed width font. Could it be a font problem?)

Daniel, there is no way to differntiate a single flowed line from a preformatted line, is there? If there isn't, I agree, that the mail.fixed_width_messages pref should also be honored for format=flowed. <xmpl> What do you think about that?: _____________ / ASCII- \ | art | --------------- </xmpl> Ideally, the first line should flow (and displayed in variable width font IMO), the following lines shouldn't (but displayed in fixed width fonts).

It's impossible to easy to differentiate a single flowed line from a preformatted using the standard, otherwise it would be an easy kill. I thought alot on that problem as I implemented it the same time as the most hysterical ASCII-art debate was filling the mail-news newsgroup. What I personally would like is a easy way to switch between fixed width and proportional width for a single window/message like you can do with a button in Eudora. Then there is really no need for displaying messages with a fixed width font as default. I wonder if there is an RFE bug on that yet...

> I wonder if there is an RFE bug on that yet... Not, that I would know of, but there is bug #20195.

This really belongs in with Daniel. Sorry guy :-) - rhp

Some more testing this morning. Here's what I found: My pref was set to display text/plain messages in variable width font. Don't know how that got there, and when I changed it in the dialog, the pref didn't stick. I then changed it by hand in my prefs.js and I now I get fixed width fonts. However, I still get <blockquote> style quoting, and I still think this is wrong. Format=flowed is really cool for soft-wrapping, and I'm happy to have it. But I think we're off the deep end here in trying to make format=flowed look like text/html, when they're really still text/plain. Changing the summary to reflect the actual problem. Filed bug 29647 on the pref not sticking.

Phil, IMHO, format=flowed is a hybrid between HTML and plain text: It flows, we know exactly, what quotes are, and we have some formatting available (with my changes). You said, you like HTML mail, so I really don't understand your position here. Anyway, does anybody have an idea, how to solve the serious technical problems with nested quotes I mentioned? The only thing I can think of, is to add a class attribute to the blockquote, like "<blockquote class=flowed>", and format it differently with a stylesheet.

Phil, I don't know what you want to achieve. With format flowed, we have enough information to show the quotes with blockquotes and looking at the two other major MUA:s supporting format=flowed, they both use the same method of displaying quoting as we do. You _could_ use some style to make the thick line look different than today but I see no point in that.

> looking at the two other major MUA:s supporting format=flowed, they both use > the same method of displaying quoting as we do. Ok, that seems like a good reason to stop where we are. I understand why it's difficult, but I hoped we had a shot at making display look just like text/plain, except with the non-quoted portions soft-wrapped. That's what I wanted to achieve.

As mozilla@bucksch.org said, the only practical way to that would be to include an internal type of blockquote to display the mails. You better speak nicely to some layout people if you want that to happen. :-) I'll mark this as WONTFIX for the time being. If someone else has an interest in doing something, please reopen the bug and reassign it.

Daniel, you don't need non-standard extensions or Gecko-changes for that. "class" is HTML 4.0 standard IIRC and you can specify a formatting via CSS. We only 1. need to insert that attribute in the flowed displayer (mimetpfl.cpp?) 2. let Mailnews use its own stylesheet (I hope, we will do that anyway in the future) 3. Let the use alter the stylesteet. If there's demand for it... The default could be not to specify anything for that in the stylesheet, i.e. status quo.

Maybe I'm dense, but isn't it enough just to wrap the lines beginning with '>' appropriately for quoted material, and then wrap those sections in a <pre>? Then, the non-quoted parts get soft-wrapped by layout, and the quoted sections stay as they were in the original message. I don't see why we need to mess with <blockquote> at all for text/plain messages.

Phil, sure, this doesn't influence non-quoted text. However, we would still have the same problems like we have in plain text today with parts: fixed lines, i.e. the recipient can't rewrap the text after the window width or whatever he likes. *In addition*, we have the following problems: - If I edit the quote (i.e. to shorten in, what I do often), I have to wrap manually. Very inconvient. - Deeply nested quotes create too long lines (due to the many "> "s). Then, either you send long lines (like 4.x) and risk, that some recipients might have problems, or you wrap it, which results in very ugly text, e.g. > > > > > spuozt ot oiszet h it prt eri tpiuerrr rrrrrroisrtoü przt owzt to > > etu üo üortüo ütr. > > > > > soert woet üutoz uüiu ü t Here, one (!) mailer in the middle decided to wrap the quote. In addition, you loose the information, that it was a quote ("> bla" is just plain text), which is a mess IMO and will propably be a violation of RFC2646.

Phil alerted me to this bug. For anyone interested in this: I'm expecting to do some work on the editor InsertAs*Quotation APIs in M15 (see bugs 29699 and 27991) and to detect flowed plaintext insertions at that time. I will plain on using <blockquote class=flowed> unless someone tells me otherwise in bug 29699, and then UE people and end users can twiddle with style to make it look the way they prefer. (Personally, I'm fine with it looking like an html quotation, I think.) Rewrapping quotations, even plaintext ones, in the editor is something Simon and I talked about, and in fact I don't think it would be that hard, if someone wants to file a separate bug to me on that. My plan is to have the editor never rewrap non-flowed quoted plaintext unless the user explicitly asks for it.

*** Bug 31045 has been marked as a duplicate of this bug. ***

*** Bug 31045 has been marked as a duplicate of this bug. ***

We should note this in the documentation somewhere.

OK, I couldn't hold back: I implemented the stylesheet change to make the border black instead of blue for format=flowed. It is intended to be a little toy for you. Bug #31047 will fix this much more complete.

I looks at CSS2, You can insert content with the ":before"/":after" pseudo-elements, but I couldn't find a way to match a line or linebreak.

Verified as won't fix.