Question:

Is there a way for Pegasus to display the lines within the message editor at the currently set right margin while I am typing?

 
ie: if set to 70 characters (monospaced style as per plain text) then by using Control J or reflow of paragraph the text would display with the line breaks as per the right margin? [ will reset mine to 65 characters in the Tool | Options for both pop and IMAP accounts/identities ]

 
If this can be done ( I think this is what I was trying to ask at the start of this thread) then my question is answered. As people have noted the target application will display as per the end user including any funky fonts, message viewer width etc. As I noted at the start, the error is most likely at my lack of understanding just asking for help in understanding.

 

Having a small problem, should be easy to fix....

Sending out plain text message, message width is set to 6.5 inches in the Option screen. Looks good in the editor and the copy to self folder. If I BCC to a second account the line breaks within the sentence making it look very poor to say the least.

If I look at the file to seems to be breaking the line at little over 72 characters with a hard return. This is with another client (Sylpheed) and via the web interface (Fastmail).

What option do I need to set? Or is the screen font the root of the problem - not using courier, but a tt font that is mono spaced.

Plain text messages are just that.  There is no formatting either at your end, as the composer, or at the receivers end. Both ends are free to choose whatever font and size they wish.   Setting message width to 6.5" sounds a little too large, try setting it down to 5.5"  That should allow viewing with a default font size of 10 or 12

Martin 

Seems when I use plain text for sending while having another font (other than courier 12 point) in the edit window causes 'bad' line breaks at the target end. The email that raised the flag for me had a linebreak at 90 characters not 70-72. Checking the email there was no hard return nor linefeed at approx 70 characters, there was a hardbreak at 90 characters.

 Will try reseting my compose font to courier new. Did not think it would have mattered what font I used if plaintext sending was selected. Just seemed to be odd.

As you say it is most likely at my end and just  trying to figure out what and or why this happened.

[quote user="aderoy"]Will try reseting my compose font to courier new. Did not think it would have mattered what font I used if plaintext sending was selected.[/quote]

It doesn't. That's why Martin Irelam says above that the font face and font size are not specified in plaintext messages.

Where and how lines break is a recognized problem with email communication, which is why the newer RFCs specify a means of sending text "flowed":

http://www.faqs.org/rfcs/rfc3676.html

(See section 3.2 specially.)  What this specification amounts to is indications of how lines are to be patched back together again -- because broken by hard breaks they must be for sending on the wire -- for backwards-compatibility. Even if I sent a plain text email to you from my copy of Apple Mail on Mac (which uses the format=flowed spec.) then your copy of Sylpheed that you mention would still display it with the lines broken at 72 characters, because Sylpheed, so far as I know, wouldn't understand the Content-Type statement in the email header and wouldn't know how to put the lines back together again.

If it's of particular importance for your recipient to see a particular layout then you'll need to send your message as HTML. Either that, or attach it as a PDF.

The use of plain text is for a reason, the line breaking at the 'wrong' point of a paragraph looks unprofessional. Line width is set for 70 characters, paragraph may have 200 characters in it. Should matter not what the client at the far end is using.

The text was a reply to a job posting, to my horror the lines broke rather badly in the bcc to the target (most likely Outlook from the header), a second account, poorly in the 'copy to self',  looked ok in the message editor. I did a Control J to make sure the text wrapped at 70-72 characters and not the screen width - which was wider still. Should this have not shown the line wrapping correctly? It does in Sylpheed & Mulberry wished the same for Pegasus which is my client of choice when using WinXP. Mulberry and Sylpheed are used under Linux or Mac when I use those platforms.

Yes I could have used HTML or a pdf but did not wish to send the extra attachments etc. Nor should I have to inorder to send an email.

As when I use LaTex, I do not worry about the lines just the paragraph. From what you are typing this is incorrect due to the rfc. Line wrap set to 70 characters should also display so in the copy to self (which is within Pegasus) and also if bcc'ed to my current account via Pegasus. This was not the case. Why is this?

Not to be critical but something is not working as it should, trying to find out what is wrong -- even if it is me so I can use the work around next time.

This is similar to the mbx import/export, does not work very well. Told to use an IMAP server if I need to transfer emails. Why? if mbx is a supported filestore does Pegasus break the email messages? Makes it difficult for me to get people to use the program if they can not get thier emails transferred in without lost. I have been using this application only for a few years -- 1999 July to be exact.

To me it points to older code that needs a refresh which David is working on.

If you read the RFC you quote, it suggests a line length of 66.  Either way, if the line length of sender and recipient are different then there will be conflict. Fortunately Pegasus Mail can handle most line overflow conditions by a simple mouse click.   But as it states in the RFC, the only way to have true "flow" is to use a data stream that understands paragraphs (as apposed to lines).  Of course Html is a perfect example, where resizing the screen at the recipient simply reflows the text.  This breaks down in text/plain, when aligned columns of numbers are presented in a table form. There is no way to inform the recipient of this column dependence in text/plain.

Secondly as mentioned in the RFC, international character coding, and quoted-printable conversions will not work.   So my recommendation to you is to use the richtext option in Pegasus Mail, and you will not have this formatting problem.

Martin 

Why does copy to self and bcc to self have different displays of the same email?

Yes I do know that Pegasus has the F5/Control F5 wrap and reformat of lines for message viewing. Does not help if the line wraps at 90 characters not the 70 characters in the settings with Pegasus itself (copy to self/ bcc show different)

Plaint text is just that, what does Pegasus use as a measurement? 10 or 12 Courier? Seems to matter. May be an idea to note in the next help file or faq.

 As  you state it may be best just to use Rich Text and all the extra garbage added.

[quote user="aderoy"]The use of plain text is for a reason, the line breaking at the 'wrong' point of a paragraph looks unprofessional. ... Should matter not what the client at the far end is using.[/quote]

No, indeed. It shouldn't matter what program, what device (computer, phone, etc), or what size window.

But it does, and will do for the foreseeable future. There's literally *nothing* you can do about that for plain text communication, because you can't control what software your *recipient* is using and what the capabilities of that software are.