227186 - plain-text compose text wrap issue with non-fixed font

Status: NEW

(MailNews Core :: Composition, defect)

Description

[Mike Coppins]

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.

Comment 1

[Mike Cowperthwaite]

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.

Comment 2

[Mike Coppins]

Attachment: couriernew-example 1

Screenshot 1 - Courier New - Empty message window.

Comment 3

[Mike Coppins]

Attachment: 2 - verdana - empty message window

Screenshot 2 - Verdana - Empty message window

Comment 4

[Mike Coppins]

Attachment: 3-couriernew - wraptest

Screenshot 3 - Courier New - wrap test

Comment 5

[Mike Coppins]

Attachment: 4-verdana-wraptest

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 :)

Comment 6

[Mike Cowperthwaite]

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.

Comment 7

[Mike Coppins]

Attachment: 1-couriernew-emptymessage

Reposting attachments to include only the compose message window.

Screenshot 1: demonstrating default, normal behaviour with an empty message. 
Observe lack of horizontal scrollbar.

Comment 8

[Mike Coppins]

Attachment: 1-verdana-emptymessage

Screenshot 2: demonstrating empty message but with Verdana set (not font size
changing).  Observe horizontal scrollbar which shouldn't be there.

Comment 9

[Mike Coppins]

Attachment: 3-couriernew-flowingtext

Screenshot 3: demonstrating message with flowing text, wrapping correctly.

Comment 10

[Mike Coppins]

Attachment: 4-verdana-flowingtext

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".	:-)

Comment 11

[Mike Coppins]

Re: your question about my saying "it is sent/received properly", Moz 1.5
receiving the email can read it without any wrapping issues.

Comment 12

[Mike Coppins]

I decided to find out how many characters per line were allowed when verdana was
used - 112.  Regardless of the message window size.

Comment 13

[Mike Cowperthwaite]

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

Comment 14

[Jeroen van der Ham]

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.

Comment 15

[tloehnert]

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? 

Comment 16

[Mike Cowperthwaite]

(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.

Comment 17

[Mike Cowperthwaite]

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

Comment 18

[Mike Cowperthwaite]

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

Comment 19

[(not reading, please use [e-mail] instead)]

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.

Comment 20

[buovjaga]

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