Closed
Bug 286103
Opened 20 years ago
Closed 17 years ago
plain text word wrap not displayed correctly
Categories
(Thunderbird :: General, defect)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: allard-nospam-bugzilla, Unassigned)
References
()
Details
Attachments
(2 files)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 Red Hat/1.0.1-1.4.3 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 Red Hat/1.0.1-1.4.3 Please, we need a mail client that wraps plain text lines correctly. I use plain text (HTML compose = UNCHECKED). I set wrap column = 72. My compose window works and lines are wrapped. If I examine mail message source, the text is wrapped. BUT the mail that I BCC myself is not wrapped. Just long lines. Mozialla has has this problem for years. My fix that worked for Mozilla does not work in Thunderbird. See: http://oceanpark.com/notes/howto_mozilla-mail-plain-text-word-wrap.html Reproducible: Always Steps to Reproduce: 1. Set <Account Settings>/<Composition & Addressing>/<Compose message in HTML format> = UNCHECKED 2. Set <Edit>/<Preferences>/<Composition>/<Wrap plain text messages at> = 72 3. Compose an email and BCC yourself 4. Read the email 5. Observe: no wrapping in the message window - lines are shown unwrapped! 5. Observe: <View><Message Source> shows message wrapped correctly as sent Actual Results: Message is shown without hard returns. Expected Results: Wrapped lines with hard returns are shown with hard returns. I notice that some email I receive from other people *is* correctly wrapped. Could this be the problem: Incorrectly displayed mail has: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Correctly displayed mail has: Content-Type: text/plain; charset="us-ascii" How can I force my Thunderbird to use the latter?
Comment 1•20 years ago
|
||
A good way to solve this would be to send the text as It is seen in the Compose-windows, ie. text is wrapped as you type it in but if you go back and edit so that one line is longer than the set wrap-lenght the mail will be sent like that. This supports the idea of WYSIWYG. It would also solve https://bugzilla.mozilla.org/show_bug.cgi?id=290159 since one can format code and have it sent like you formated it.
This also affects the windows version of Thunderbird version 1.0.2 (20050317) (running on Windows ME). The margins do not change dynamically with the window size but are fixed at a very wide setting (decreasing the window size merely introduces horizontal scroll bars)
In an effort to try and not open up a new bug, I'm hoping my situation most closely resembles this one. Here's the scoop: We have a Microsoft Exchange server and LDAP Server at work. The majority of the employees use Outlook, however a lot of Web Dev dept. (including myself) uses Thunderbird due to some problems with Outlook (e.g. it doesn't look at the plain text header if both HTML and text headers were sent). This is what actually happened: I sent out a message that included 2 long links in Thunderbird. I find out it was sent in plain text format. I get a response back from someone who is using Outlook. I view the response in Thunderbird. While my original message was sent out unwrapped, the reply I got back is shown as being a wrapped plain text message, and one of my links is cut off in the process (i.e. only a portion of the text is underlined and clickable). Now if I open up Outlook, the response looks normal, that is, the links aren't cut off. I tried doing a test sending a plain text in Thunderbird, viewing in Thunderbird, replying in TB, and viewing again, in TB, and it looked fine. Something must be happening to the original message when Outlook is involved in sending message(s).
Today I received a plain text message for which both the Message Source and the message display, showed the text as wrapped. As soon as I went to Forward the message, my composition window showed the text as NOT wrapped. I click Send. I look in my Sent Items folder, and indeed, the text is NOT wrapped, both in display and the message source. How come Thunderbird doesn't retain the original text-wrapping when you Forward a message (I assume reply is similar)?
Comment 5•18 years ago
|
||
The attached test.tar contains 2 eml files - test_1.eml and test_2.eml. test_1.eml is the email file that mozilla displays incorrectly and test_2.eml is the one that is displayed correctly. The difference is that the one that is displayed incorrectly has space before the end of line but the one that is displayed correctly does not have space character before end of line.
I have this same problem after finally upgrading from 1.0.8 to 1.5.09. Everything was fine prior to the upgrade. Now, if I send an email that is set to wrap at 72 characters, it does, and the message source shows it as wrapped, but the email itself is displayed as though it was not wrapped. Go figure. I tried to determine whether there were some sort of special characters used in the linewrap lines versus the actual end-of-line, but can't seem to find the email in the INBOX file. Thanks, Grant M.
Updated•18 years ago
|
QA Contact: general
Comment 7•17 years ago
|
||
Anyone see this with a recent release? If so can you attach a screenshot.
Assignee: mscott → nobody
Comment 8•17 years ago
|
||
Screenshot of the test_1.eml.
Updated•17 years ago
|
Attachment #296941 -
Attachment description: Screenshot of the problem → Screenshot of the problem (Thunderbird 2.0.0.9)
Comment 9•17 years ago
|
||
I see what you mean now - it's not a bug. test_1.eml is a valid format=flowed message, test_2.eml falsely claims to be - it would need space at the end of the rows to be one. Format=flowed messages are supposed to work just the way that screenshot shows, avoiding unnecessary line breaks. Anyways, if you don't like it, there is a pref you can set to get the wrapped at some line length behaviour. Set mailnews.display.disable_format_flowed_support to true for that. ->INVALID
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•