Closed Bug 101877 Opened 23 years ago Closed 21 years ago

"wrap text to fit window width" feature joins shorts lines of text!

Categories

(SeaMonkey :: MailNews: Message Display, defect)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: nelson, Assigned: sspitzer)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

mail message demonstrates problem
4.57 KB, text/plain
Details 
The "wrap text to fit window width" feature should only wrap lines of text 
that are wider than the window width.  It should leave short lines alone.
But in plain text email messages, this feature actually lengthens short 
lines by taking words from the following lines.  

The problem seems to occur on the first line of a paragraph, that is, on
the first line following a blank line.  If the first line after a blank
line is shorter than the window width, such that there is room on that 
line to include words from the following line, then a word or words are
taken from the following line to lengthen that line.
Summary: "wrap text to fit window → "wrap text to fit window width" feature joins shorts lines of text!
I am using N6.x  build 2001091703.
More info about this.  The problem of lengthening short lines occurs 
sometimes even when the "wrap text to fit window width" feature is disabled.

I have a plain text message that has several paragraphs that exhibit this
line lengthening behavior.  With the "wrap text to fit window width" feature
enabled, more lines are lengthened than when it is disabled, but some lines
are lengthened even when it is disabled.  I will attach a copy of the message
to this bug.

The paragrpah that begins with "I see the problem" is always lengthened by
having the first (and only) word from the following line joined to it if 
the window is wide enough, regardless of the setting of the feature.

The very next paragraph has the first word from the second line joined to the 
first line, but only when the feature is enabled.
Blocks: 157217
I confirm the bug in moz 1.0.2 1.3a 1.3b 1.3.
Bug 167634 has additional information about this behaviour. This bug is still
around, at least in the following versions:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529
See bug 167634, comment 14 and follow-ups in particular.
Julian (julian[at]sektor37.de) has already mentioned what I was going to write.
I'm just adding myself to the CC list. Also, confirming behaviour, as well as
the one mentioned in Comment 3, on Windows XP Pro:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529
I was mistaken, meanwhile it seems like the Viewer component works correctly;
instead, there is a bug in outgoing mail. So this bug should probably be marked
a duplicate of bug 167634. 

Bug 167634 comment 22 points to the underlying reasons. Bug 167634 comment 24
attempts to detail the problem in length. Bug 167634 comment 25 is a brief
summary of what needs to be done.

Let me add that Bug 167634 comment 26 points to an attachment that shows that
the viewer component works correctly. 

RFC2646, pointed to by Bug 167634 comment 22 also makes clear why Nelson
couldn't explain that sometimes lines were concatenated, sometimes not. I
haven't checked, but I bet that mail has whitespace after some lines, and not
after others. 

This still doesn't clarify the role of the "wrap text to fit window width"
switch, though.

The message attached above claims to be format flowed, and some lines do and
others do not have trailing blanks.  You're right that it explains the 
observed behavior with the message.  Thanks for looking into this.

But I question the solution proposed in Bug 167634 comment 25.  As I 
understand it you propose to strip all trailing blanks in the outgoing 
message, making them all fixed length.  What sense does it make to send 
a message that claims to be flowed format, but has all fixed length lines?  
Why not just change the outgoing message's format parameter to declare the 
message is fixed format?

I like your idea of giving the composer user a button to choose between 
flowed format and fixed.  But then, if the user chooses flowed, then 
stripping trailing blanks from outgoing text is a bad idea, no?

Suggestion: make the  "wrap text to line width" pref be a 3-valued preference,
with settings :  always, never, only when format=flowed.

The solution I posted in Bug 167634 comment 25 was one possible solution and
perhaps a summary too tight. As I mentioned in the long comment, of course
stripping the header is another option, and you're right that it's probably the
more elegant one (though the outcome should be the same.) I also said there that
for format=flowed messages, whitespace must be left.

Regarding the setting, are we talking about the same thing? I meant a setting
for outgoing mail, you seem to be talking of a setting for the viewer. Perhaps
it would be nice to have both, but in the context of bug 167634 it's about
wrapping of outgoing mail. Or what do you mean by "only when format=flowed", do
you mean the user should choose between plain format and flowed format at one
place, and choose the wrapping at a different place?


Why not make it all in the same place? Add the "wrap text at XX" message along
with the third option. Would that work?
There is a mail display preference called "wrap text to fit window width".

This bug complains that the mail reader apparently ignores the setting of 
that preference, continuing to wrap text when the preference says not to.

Your comments made it clear that the problem is related to format=flowed,
and your last sentence in comment 10 makes it apparent that the meaning 
of the preference described above is unclear in the presence of flowed format
text.  

So, in comment 11, I suggest that we change the mail display preference to 
offer these choices (for displaying)
   - Never wrap text, not even when format=flowed
   - Alway wrap text, even when format=fixed (explicitly)
   - Wrap text when format=flowed and not otherwise

In bug 167134, you suggested having buttons that tell the composer whether to
use format=flowed for format=fixed for outgoing mail.  I don't know whether
you were proposing a preference or a pair of buttons in the composer window
itself.  In comment 11, I said I also like this idea.  Perhaps I should have
put that comment in bug 167134.  
OK, got it now. We are dealing with two different sets of options: one for
formatting outgoing mail, and one for wrapping in the viewer component.

The options for outgoing mail should be/have been discussed in bug 167634.

For the viewer component you suggested the following three options:
   - Never wrap text, not even when format=flowed
   - Alway wrap text, even when format=fixed (explicitly)
   - Wrap text when format=flowed and not otherwise

I'm not sure how useful the first option "never wrap" is. Format=flowed is all
about wrapping at the receiver end, so I don't think non-wrapped display of a
(properly formatted) format=flowed message makes any sense.

Therefore I'd like to suggest to wrap format=flowed messages in any case, and
have the following preference for format=fixed messages:

   [X] Force wrapping of preformatted messages  (checkbox)

This corresponds to your suggestion, without the "never wrap" option.

I would suggest "preformatted" (sp?) as a user-friendly way of denoting
format=fixed messages, but perhaps someone can come up with a better label.

I think the default should be "do not force wrapping of preformatted messages"
(checkbox disabled.)

Julian wrote:

>  I don't think non-wrapped display of a (properly formatted) format=flowed 
> message makes any sense.

OK, but that choice is to make the message readable when it contains an 
improperly formatted format=flowed message, like the one that triggered 
this bug report in the first place.  That's precisely what I want.

So, the rest of your proposal doesn't work for me.
Yes, you're right. I didn't think of that.

(following copied from bug 167634)

See bug 168420. Seems like there's a LOT to say about format=flowed.

I still think something is wrong with the system, probably the viewer. It's kind
of unnatural that the viewer concatenates only full text lines, not on the word
level. I think that's not how RFC2646 is meant.

I would like to distinguish between "wrapping" and "flowing" -- "flowing" occurs 
with an f=f message (and with f=f display enabled), where lines are joined; 
"wrapping" occurs where the flow of text is broken from one line to the next.  A 
flowed line often should be wrapped (to a column, or to the window edge).

Nelson Bolyard: if I understand your comment 16 correctly, you want to see 
Mozilla flow lines even if they are improperly coded with f=f.  I don't know 
that this is possible.  You are asking that Mozilla distinguish between:

   This is my paragraph, which is flowing and flowing#
   and flowing, and I end it here!
   And start a new paragraph here...

and

   This is my paragraph, which should flow except I inadvertantly#
   type Enter here!
   but I really wanted the paragraph to continue with this line...

(where # indicates a trailing space on the line, and ! indicates a hard break). 
I don't believe it can be done in a way that wouldn't screw up other people's 
specifically-formatted mail.

I am inclined to mark this bug as Invalid, as I did with bug 167634, but if you 
have a specific proposal to get the behavior you want, please post it here.
Mike, I am definitely not proposing what you think.  

25 months ago, when I wrote this bug, there was no way (AFAIK) to disable
flowing in the composer or in the mail viewer.  I incorrectly believed 
that the "wrap text to fit window width" preference for the mail viewer 
also controlled flowing, and that disabling wrapping would/should also 
disable flowing, but I observed that it did not, and I thought that was
a bug.

In essence, what I wanted was a way to disable flowing, so that when one
read a received email that was an improperly-formatted flowed message, 
one could read it as if it had not been marked format=flowed.  I thought
that turning off wrapping should do that.  

In the end, what I want is the ability to disable the flowing of text in 
the display of a received flowed message.  I want to be able to change 
this on a message by message basis, without having to change a preference, 
just as one can now change the "text zoom" or "character set" for each 
message. (I'd similarly like to be able to enable/disable wrapping without
changing a preference).

If there is now, 25 months later, a way to disable flowing in the mail
reader (I'm not discussing the composer), then I suppose this bug can be
marked fixed or worksforme.  

Oh, feel free to change the subject of this bug as "no way to 
disable flowed format in mail viewer".
It is certainly possible to disable flowed support, but not terribly convenient
(see bug 86607).  These two preferences control it:
   mailnews.display.disable_format_flowed_support    controls f=f in display
   mailnews.send_plaintext_flowed      controls f=f in composition
The first is the one you want.  You can set the value by going to the browser 
and visiting   about:config    then type 'flowed' into the filter field.  
Double-click the preference, and set it to "true" -- then reload the message.

And so with that, I will resolve this bug as Invalid.  Thanks for letting us 
know.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
I disagree that this bug is invalid.  It was fixed by the addition of a new
feature in the 25 months after it was filed, namely, a feature to explicitly
control format=flowed in display.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: