How to stop Outlook/Winmail from removing line breaks as e-mail se

J

Jochen Wezel

I want to send a plain text email by code to receipients using Outlook or
WinMail.

Unfortunately, Outlook and Winmail remove line breaks automatically -
catastrophically.

Can I add a header to the e-mail to stop outlook/winmail from doing some
automatic magic regarding the line breaks? Or is there another way to force
Outlook/Winmail to stop removing any linebreaks automatically?
 
V

VanguardLH

Jochen said:
I want to send a plain text email by code to receipients using Outlook or
WinMail.

Unfortunately, Outlook and Winmail remove line breaks automatically -
catastrophically.

Can I add a header to the e-mail to stop outlook/winmail from doing some
automatic magic regarding the line breaks? Or is there another way to force
Outlook/Winmail to stop removing any linebreaks automatically?

It is an option setting on the user's host in their copy of Outlook
(don't know what is WinMail since there is no MS product by that name).
Your e-mail does not get to control how the recipient configured their
e-mail account. Would you want someone doing that to you? Do you also
configure your Outlook to use the Internet security zone (instead of the
Restricted Sites security zone) so anyone sending you an HTML-formatted
e-mail can run scripts on your host?

Rather than send in plain text format, you could use HTML. Then enclose
your code fragment inside <PRE>texthere</PRE> tags. That will render
the HTML so that whitespace is honored as it is entered inside those
tags.
 
J

Jochen Wezel

(don't know what is WinMail since there is no MS product by that name).
WinMail is the email application of Windows Vista.
--> this problem is very special to Microsoft email applications.
Your e-mail does not get to control how the recipient configured their
e-mail account.
It has nothing to do on how to configure general e-mail settings. It is the
question how to control automatisms regarding appearance of content. For some
reasons, automatisms make sense, but not in all reasons. So there is the need
to be able to switch off this automatism if you know it's not working
properly within special situations.
Rather than send in plain text format, you could use HTML.
This is an option (or let's say a workaround) in many situations, but not a
real solution. I'm interested in a real solution.
Only 1 argument of several ones why a real solution is required: the SPAM
detection engines do another ranking if you use text-only, html-only or
text+html-mails.
 
B

Brian Tillman [MVP - Outlook]

I want to send a plain text email by code to receipients using Outlook or
WinMail.

Unfortunately, Outlook and Winmail remove line breaks automatically -
catastrophically.

When using Plain Text, you have no control over the formatting that the
recipient sees. The display is controlled on the receiving side.
Can I add a header to the e-mail to stop outlook/winmail from doing some
automatic magic regarding the line breaks? Or is there another way to force
Outlook/Winmail to stop removing any linebreaks automatically?

Outlook (I haven't tested Windows Mail) does not remove line breaks on the way
out. It can, however, remove them when receiving. Tools>Options>E-mail
Options>Remove extra line breaks in plain text messages.
 
V

VanguardLH

Jochen said:
WinMail is the email application of Windows Vista.
--> this problem is very special to Microsoft email applications.

Microsoft has always referred to this product as Windows Mail. Example:
http://www.microsoft.com/windows/windows-vista/features/mail.aspx, and
WinMail is not used anywhere. WinMail is a colloquialism employed by
some users of the product.

WinMail, as another example, could refer to a 3rd party product called
WinMail Viewer, that is used by recipients of e-mails where an Outlook
sender chose to compose using RTF format that no other e-mail client
supports. When you said WinMail, that was the first product that I
thought of because that word is actually in the name of that product.
It has nothing to do on how to configure general e-mail settings. It is the
question how to control automatisms regarding appearance of content. For some
reasons, automatisms make sense, but not in all reasons. So there is the need
to be able to switch off this automatism if you know it's not working
properly within special situations.

So, again, you want to change what the recipient see despite what
configuration they have chosen for their e-mail client running on their
property. Scripts aren't allowed in e-mail for the same reason.
This is an option (or let's say a workaround) in many situations, but not a
real solution. I'm interested in a real solution.
Only 1 argument of several ones why a real solution is required: the SPAM
detection engines do another ranking if you use text-only, html-only or
text+html-mails.

All HTML-formatted e-mails should contain 2 MIME parts: a plaint-text
MIME part and an HTML MIME part. Not all e-mail clients can read
HTML-formatted e-mails, or users have configured their e-mail clients to
always show e-mails in plain-text format. The text MIME part ensures
that your e-mail is viewable by as many recipients as possible. It is
improper to compose an HTML-formatted e-mail without including a
plain-text version. Hotmail was like that for a long time but, as I
recall, they redeemed themself by eventually including both MIME types.

If some anti-spam filter is adding spam weight to an e-mail that
contains both text and HTML MIME parts than the author of that software
hasn't a clue how HTML-formatted e-mails are supposed to be composed, or
the user of that software misconfigured it.

About the best you can do if you decide to stick with plain-text e-mails
is to put a notice at the top of your e-mail notifying the user to NOT
have their e-mail client remove duplicate blank lines. Of course, in
Outlook, a yellow infobar already comes up to warn the user that Outlook
has removed the extra blank lines.

Since you don't want to use HTML, sending a .pdf, .doc, .txt, or other
file as an attachment that contains your code is probably not a viable
solution to you. However, I suspect your recipients would probably want
your code as an attachment rather than inside the body of the e-mail.
For example, when they reply, they're going to have to do a lot of
snipping out of that code that isn't needed in their reply.

Personally I don't see how code is any harder to read when it is
single-spaced with just a blank line for whitespace to provide
legibility than to double up, or more, on the blank lines. Reading
books, and even reading code, is a lot tougher when they're
double-spaced. You could, for example, place a single period character
at the start of the blank lines (if that doesn't interfere with whatever
is the data you are providing inside the e-mail). That wouldn't be a
blank line so it won't get removed as duplicate whitespace. I haven't
tried inserting just a tab character (which appears invisible to the
user) to see if that might qualify the line as non-blank to circumvent
the duplicate whitespace removal.

Of course, the removal of duplicate contiguous blank lines is a feature
in Outlook. Who know what another e-mail client might do with your
e-mail regarding whitespace.
 
J

Jochen Wezel

Yes, there are many possible workarounds for handling specific situations.
My task is to develop a solution that works in general/all situations.

So, text shall be text and no attachment, adding periods to some line
requires a logic specifically for the content logic of a special e-mail
message. The text is no long text, it is just a simple mail with around 10 or
20 lines. Easy to read and to understand if it is displayed directly. But it
must appear in a format so that the eye can realize the structure of the
small table inside or the structure of the document realized by paragraphs.

All workarounds always have a negative point with it. For a general
solution, it is not possible to work around any issues. It just has to work
smoothly.
 
J

Jochen Wezel

Hi Brian,
When using Plain Text, you have no control over the formatting that the
recipient sees. The display is controlled on the receiving side.
yes, this exactly is the point that leads to these problems. It wouldn't be
a problem if the automatism would work more intelligent and don't break down
a required document structure. After the automatism, the document must keep
easy to read for the eye, easy to see the structure of a document, easy to
read some small table data.

If this is not possible, you have done one major mistake: you have "thought"
as developer for the user. The central mistake of it is: the developer can
never realize the full reality at the user's side; so, this leads to many
frustration at the user's side if it doesn't work as expected. Alternatively,
you can say: the mistake was to provide an automatism which hasn't been
tested enough.

That's why I request to either
1. switch off the automatism per default (it should better be enabled
manually by a check box in the email options)
2. provide a possibility for the senders (developers who know about what
they're doing and who know how the e-mail shall appear) to switch off the
automatism by an additional mail header if they know that the automatism
(which won't work in all situations as perfect as the authors hoped it to do)
crippled the document structure.

Since these automatisms are included into outlook since Outlook 97 (as far
as I know), the fix should apply to all versions starting with Outlook 97 as
best. But at least Outlook 2007 is a must.

Thanks,
Jochen
 
B

Brian Tillman [MVP - Outlook]

That's why I request to either
1. switch off the automatism per default (it should better be enabled
manually by a check box in the email options)
2. provide a possibility for the senders (developers who know about what
they're doing and who know how the e-mail shall appear) to switch off the
automatism by an additional mail header if they know that the automatism
(which won't work in all situations as perfect as the authors hoped it to
do)
crippled the document structure.

If you think a change is needed in Outlook, then you'll need to contact them.
Posting in this newsgroup doesn't accomplish that because Microsoft employees
rarely read this newsgroup and it's not an official support channel. Again, I
don't believe Outlook (on the sending side) has anything to do with this and
you'd have to make changes in ANY of the myriad clients your recipients use.
 
L

Loophole64

VanguardLH;14462 said:
Jochen Wezel wrote:

It is an option setting on the user's host in their copy of Outlook
(don't know what is WinMail since there is no MS product by tha
name).
Your e-mail does not get to control how the recipient configured their
e-mail account. Would you want someone doing that to you? Do yo
also
configure your Outlook to use the Internet security zone (instead o
the
Restricted Sites security zone) so anyone sending you a
HTML-formatted
e-mail can run scripts on your host?

Rather than send in plain text format, you could use HTML. The
enclose
your code fragment inside.

:eek:

What an obnoxious response. The guy is asking a totally legitimat
question. Email clients back to the beginning of email have honored lin
breaks. Outlook's behaviour is well outside of the norms and this is
common problem.

You DO get to control things about your email. You control the content
if Outlook decided to start replaceing the word hi with the word Hola
or replaced periods with carot symbols, would you be such a punk in you
response?

Allowing SCRIPTS to run and allowing BASIC ASCII CHARACTERS is just no
even in the same realm. If you're going to be so antagonistic, yo
shouldn't even respond. This is not a "code fragment," it's a lin
break. Good lord. :confused:

end rant

So there is in fact a <b>solution</b>. If you begin each line of you
email with two spaces, Outlook will not remove your line breaks. ;)

There, was that so hard Vanguard? if you don't have a solution, don'
respond just to be an ass. :rolleyes
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top