Open Bug 227186 Opened 17 years ago Updated 3 years ago
plain-text compose text wrap issue with non-fixed font
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Situation: A user does not like using the Courier New font for viewing/composing/replying emails. Options (relevant, IMO) changed from defaults: * message display: fixed-width font * send format: convert to plain text * mail account setting: untick 'compose messages in HTML format' The quickest way to change the font in this situation that I've found is to set the Prefs > Appearance > Monospace font to Verdana for example. It's not fixed-width I know, but we're talking about a user who isn't worried by the aesthetic issues which may result. The problem which results is that when a compose/reply window is opened, is that text doesn't wrap to the window. It is sent properly, and appears at the receiving end looking ok. I think the 72 character setting is being observed as soon as the compose/reply window is opened, by the looks of the wrap width. Another odd thing that happens is that the horizontal scrollbar kicks in as soon as the compose/reply window is opened, even though there is no overflowing text requiring its presence. Reproducible: Always Steps to Reproduce: 1. 2. 3.
I'm not sure why the font has anything to do with this bug. Don't you see the same results -- reply text wrapped to a specific width -- with Courier New or any other font? I guess it could be more noticeable with Verdana because that's a narrower font overall -- if the default window size is just about where the monospace font breaks at col 72, you might think there's a difference. In either case, tho, resizing the window does not reflow the quoted text. Mozilla does not automatically wrap or reflow the quoted text within a plain-text compose window, once that window has been opened. If the original text is reflowable (an HTML message, or plain-text format=flowed), it will be initially reflowed to the specified column, then indented by the "> " prefix. If the original text is not reflowable, it will be quoted with line breaks as they exist within the original message, which in some cases means very long lines. See: bug 173918; bug 196033; bug 208128 You're right, tho, that the scrollbar is an oddity, and probably that's a side-effect of the variable-width font -- Mozilla probably assumes a text width of n 'X' characters (or something) which exceed the actual width of most text. The scrollbar disappears if you widen the window. Unless there's some problem here that I've overlooked, I recommend closing this as Resolved|Invalid -- the program is working as designed.
Screenshot 1 - Courier New - Empty message window.
Screenshot 2 - Verdana - Empty message window
Screenshot 3 - Courier New - wrap test
Screenshot 4 - Verdana - Wrap test Now, all of these window sizes and positions are identical, and I've checked that Verdana is thinner than Courier. The screenshot looks exactly the same if I had opened a new compose window and retyped the text. Something is up the creek :)
First: May I suggest you supply images only of the window in question? Some of us are on dialup. Second: the first two images add nothing to the discussion. I misunderstood your original report, I thought you were talking about the quoted text in a reply. However, just because I've made things more confusing is no reason to retaliate. :) It does seem to be wrapping on the text according to a width rather than a character count -- again, that width might be 72 'M' characters or 72 'W' or some such. The plain-text composer obviously starts with the assumption that its font is fixed-width and calculates its expected width accordingly. Note that when using a fixed-width font, if you reduce the width of an empty compose window, the scrollbar will be displayed once the window gets below the expected 72-character width. When you say "It is sent properly" do you mean the outgoing text is in fact wrapped to 72 characters? I'm confirming this bug, since I couldn't find a dupe anywhere. I'm reducing the severity, since the workaround is fairly simple and since the user "isn't worried by the aesthetic issues which may result." I'm also updating the summary to be, I hope, a little more precise.
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: compose/reply text wrap issue after font change → plain-text compose text wrap issue with non-fixed font
Reposting attachments to include only the compose message window. Screenshot 1: demonstrating default, normal behaviour with an empty message. Observe lack of horizontal scrollbar.
Screenshot 2: demonstrating empty message but with Verdana set (not font size changing). Observe horizontal scrollbar which shouldn't be there.
Screenshot 3: demonstrating message with flowing text, wrapping correctly.
Screenshot 4: demonstrating message with flowing text in verdana font, but wrapping past the window border, despite verdana apparently being a thinner font than courier new (confirmed as well using Notepad and OpenOffice). I'm on a modem too. :-) The issues I've described limit Mozilla's user-friendliness in that its users can't specify a different font and not come across issues. I said "isn't worried by the aesthetic issues which may result." wrt fixed-width versus variable-width. To quote the user who informed me of these issues, "it looks naff". :-)
Re: your question about my saying "it is sent/received properly", Moz 1.5 receiving the email can read it without any wrapping issues.
I decided to find out how many characters per line were allowed when verdana was used - 112. Regardless of the message window size.
Component: Mail Window Front End → Composition
OS: Windows 2000 → All
Hardware: PC → All
*** Bug 261924 has been marked as a duplicate of this bug. ***
Perhaps it is good not to change the wrapping behavior (although I think it's odd), but limit the choice a user has for the monospace font. I know I had to use another application to find out which fonts were exactly fixed-width, so that I could select them from the (long) list available for the monospace font. Or perhaps change it so that the font selection is more hierarchical so that you select the font-kind first and then the specific font.
I did a little testing on this bug (Linux,version 0.8 (20041027)): changing monospace font to variable-width font (e.g. Verdana) leads to the following behavior: 1. set "wrap plain text messages at" to 20 -> the compose windows wraps after 40 characters 2. set "wrap plain text messages at" to 72 -> in the compose wraps at 144 characters. So it looks like a pattern "compose window wraps at 2 x (wrapping plain text preference)". The sending of the messages is, however, always done correctly. Now, what I do not get about this bug is: why do you care about the font-type at all when calculating word-wrap that is defined in *characters*? Of course when calculating wrap as per *window size* is a different story - but not in this case. Or do I miss someting? Summing it up, I find this bug rather annoying because: 1. It breaks WYSIWYG for the user, i.e. what you type is not what you send. 2. Especially Linux user are likely to change font settings for various font renedering issues (certain fonts look ****, choosing ttf fonts, etc...) 3. I'm not aware of any RFC/STD that *requires* fixed-width font for the text/plain message format; RFC 2646 merely states: "Text/Plain is usually displayed as preformatted text, often in a fixed font." -> "Often in a fixed font" i.e. it is *common* to use (because it makes sense to have lines displayed with similiar width) but it is by no means a requirement and it does not break the interoperability for the text/plain format. Therefore: why not let the user have it his way?
(In reply to comment #15) > So it looks like a pattern "compose window wraps at 2 x (wrapping plain text > preference)". Which characters were you typing to test that? With Verdana under Windows, I just tried with wrap set to 72. If I type repeated strings of "aaaaaaaaa " (9 'a' plus a space), the wrapping occurs after the 10th string of a's. If on the other hand I type repeated strings of "iiiiiiiii " (9 'i' plus a space), the wrapping occurs after the 24th string of i's. Clearly, this is *not* a simple 2:1 ratio; the wrapping is occurring at a specific width. > Now, what I do not get about this bug is: why do you care about the font-type > at all when calculating word-wrap that is defined in *characters*? Of course > when calculating wrap as per *window size* is a different story - but not in > this case. The reason that's being done on a width, rather than on characters, is because the wrapping is being handled at the Gecko layout level, and distances are not defined in character widths there. There would have to be an entirely new wrapping technique coded to actually be counting characters. In fact, I can't think of any program (word processor, editor, mail program, etc) that allows editing in a proportional font but still wraps lines at a particular character count. > It breaks WYSIWYG for the user, i.e. what you type is not what you send. > [...] > Especially Linux user are likely to change font settings for various font > renedering issues (certain fonts look crappy, choosing ttf fonts, etc...) Unless your position is that monospace fonts are never appropriate, selecting a proportional font for the monospace setting makes no sense. It affects mail you receive as well as that you send -- breaking the *sender's* expectations that you will Get what they See. > I'm not aware of any RFC/STD that *requires* fixed-width font for the > text/plain message format; RFC 2646 merely states: > > "Text/Plain is usually displayed as preformatted text, often in a fixed font." That is about message display, not message editing. In fact, there is a setting in Moz/TB, with UI in the Preferences, to display plain-text messages in the variable-width font. > Therefore: why not let the user have it his way? It *does* let you have your way. It also lets you set the foreground and background to both be the same color, if that is your way. The presumption is that the user is intelligent enough to grasp some of the basic facts about how the software works -- about how data is presented in these modern Web-ensnared days -- and will make appropriate settings accordingly. If you really want to do mail editing with a proportional font, the recommended technique is to use the HTML mail editor but send as plain text. But, that still won't wrap at 72 characters during the edit. I recommend this bug be WONTFIX'd.
Noted in the newsgroups: this symptom also occurs when using a font-family override in userContent.css, a technique presented at this FAQ: http://www.holgermetzger.de/efaqmailnews.html#26
*** Bug 285089 has been marked as a duplicate of this bug. ***
sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
Still repro. Not marking as wontfix per comment 16, but someone could consider doing it.. Thunderbird 52.1.0 (32-bit) Windows 7 64-bit
You need to log in before you can comment on or make changes to this bug.