Re: Double Spacing in Mails from Sendmail
This WebDNA talk-list message is from 2002
It keeps the original formatting.
numero = 42868
interpreted = N
texte = > By which you mean you are going to fix it? Soon? I've been > complaining about > this for literally years. And it didn't always misbehave like this... Of course, John. I just though it would be nice to explain what was going on. That code hasn't changed in years, so it must have been an issue for quite some time.> OK, that't just plain wrong! Your code (i.e. WebCat) has no > business messing > with the EOL characters, ever, on platforms that do not need > it, like Windows. Again, I was just explaing what was going on. I certainly was not proposing that the code is correct as is. >I believe you are not understanding text mode correctly > under Win*, since > that is supposed to treat CR/LF as \n and automatically > upgrade CR => \n for > you. Straight from the MS docs...(regarding a file that is opened in text mode)... Also, in text mode, carriage return-linefeed combinations are translated into single linefeeds on input, and linefeed characters are translated to carriage return-linefeed combinations on output. I've confirmed this to be true, If my test email body contains a
sequence, after the fwrite() call, the email text file contains a sequence. > I'll bet dollars to donuts you have a \r in the fprint(). Nope. The message body is written out using fwrite(), no '\r' characters involved. But because the file was opened in text mode, characters are converted as I explained previously. I think this was just an oversight when the WebDNA engine was ported to the Windows platform. Sorry it took so long to get to the bottom of this issue. > -----Original Message----- > From: WebCatalog Talk > [mailto:WebDNA-Talk@talk.smithmicro.com]On Behalf > Of John Peacock > Sent: Friday, August 23, 2002 3:55 AM > To: WebCatalog Talk > Subject: Re: Double Spacing in Mails from Sendmail > > > Scott Anderson wrote: > > Looks like a [sendmail] bug (but only on the Windows platform) > > By which you mean you are going to fix it? Soon? I've been > complaining about > this for literally years. And it didn't always misbehave like this... > > > > > The [sendmail] context opens the email file in 'text' mode, > so there is a > > translation taking place where linefeed characters are > replaced with > > carriage-return linefeed pairs . The header lines > work fine because > > [sendmail] explicitly inserts only a at the end of > each header (which > > is then translated to pair by the fprintf() call). > But the body is > > written out as is. So if the body contains a > sequence, this > > becomes a sequence during the fwrite() call. > > OK, that't just plain wrong! Your code (i.e. WebCat) has no > business messing > with the EOL characters, ever, on platforms that do not need > it, like Windows. > I realize that WebCat started as a Mac-only package, but come > on, that was 7 > years ago! Out of the box, with no mucking about by anyone, > Windows EOL > characters will produce RFC compliant e-mails. > > The RFC's require CR/LF in the header and do not require any > special EOL > handling in the body. All compliant MTA's I am aware of will > take CR or LF or > CR/LF as an EOL character when found in the body. Any > special handling you > perform should only be directed at the header lines. > > Here's what you should be doing, and it will work for all > platforms out of the box: > > 1) For header lines only, strip whatever EOL character(s) you > find and always > output CR/LF pairs; > > 2) Do not perform any EOL modifications to body text. > > > > > A work around would be to make sure the text within your > [sendmail] contexts > > tags contain UNIX style line endings. > > > > I'll test this, but I believe that we tested this ages ago > and it did not fix > it. I believe you are not understanding text mode correctly > under Win*, since > that is supposed to treat CR/LF as \n and automatically > upgrade CR => \n for > you. On output, text mode under Windows will always give you > CR/LF, so if you > are doing anything different in the fprint(), you are causing > the problem > yourself. I'll bet dollars to donuts you have a \r in the fprint(). > > John > > -- > John Peacock > Director of Information Research and Technology > Rowman & Littlefield Publishing Group > 4720 Boston Way > Lanham, MD 20706 > 301-459-3366 x.5010 > fax 301-429-5747 > > > ------------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > > Web Archive of this list is at: http://search.smithmicro.com/ ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/
Associated Messages, from the most recent to the oldest:
> By which you mean you are going to fix it? Soon? I've been > complaining about > this for literally years. And it didn't always misbehave like this... Of course, John. I just though it would be nice to explain what was going on. That code hasn't changed in years, so it must have been an issue for quite some time.> OK, that't just plain wrong! Your code (i.e. WebCat) has no > business messing > with the EOL characters, ever, on platforms that do not need > it, like Windows. Again, I was just explaing what was going on. I certainly was not proposing that the code is correct as is. >I believe you are not understanding text mode correctly > under Win*, since > that is supposed to treat CR/LF as \n and automatically > upgrade CR => \n for > you. Straight from the MS docs...(regarding a file that is opened in text mode)... Also, in text mode, carriage return-linefeed combinations are translated into single linefeeds on input, and linefeed characters are translated to carriage return-linefeed combinations on output. I've confirmed this to be true, If my test email body contains a sequence, after the fwrite() call, the email text file contains a sequence. > I'll bet dollars to donuts you have a \r in the fprint(). Nope. The message body is written out using fwrite(), no '\r' characters involved. But because the file was opened in text mode, characters are converted as I explained previously. I think this was just an oversight when the WebDNA engine was ported to the Windows platform. Sorry it took so long to get to the bottom of this issue. > -----Original Message----- > From: WebCatalog Talk > [mailto:WebDNA-Talk@talk.smithmicro.com]On Behalf > Of John Peacock > Sent: Friday, August 23, 2002 3:55 AM > To: WebCatalog Talk > Subject: Re: Double Spacing in Mails from Sendmail > > > Scott Anderson wrote: > > Looks like a [sendmail] bug (but only on the Windows platform) > > By which you mean you are going to fix it? Soon? I've been > complaining about > this for literally years. And it didn't always misbehave like this... > > > > > The [sendmail] context opens the email file in 'text' mode, > so there is a > > translation taking place where linefeed characters are > replaced with > > carriage-return linefeed pairs . The header lines > work fine because > > [sendmail] explicitly inserts only a at the end of > each header (which > > is then translated to pair by the fprintf() call). > But the body is > > written out as is. So if the body contains a > sequence, this > > becomes a sequence during the fwrite() call. > > OK, that't just plain wrong! Your code (i.e. WebCat) has no > business messing > with the EOL characters, ever, on platforms that do not need > it, like Windows. > I realize that WebCat started as a Mac-only package, but come > on, that was 7 > years ago! Out of the box, with no mucking about by anyone, > Windows EOL > characters will produce RFC compliant e-mails. > > The RFC's require CR/LF in the header and do not require any > special EOL > handling in the body. All compliant MTA's I am aware of will > take CR or LF or > CR/LF as an EOL character when found in the body. Any > special handling you > perform should only be directed at the header lines. > > Here's what you should be doing, and it will work for all > platforms out of the box: > > 1) For header lines only, strip whatever EOL character(s) you > find and always > output CR/LF pairs; > > 2) Do not perform any EOL modifications to body text. > > > > > A work around would be to make sure the text within your > [sendmail] contexts > > tags contain UNIX style line endings. > > > > I'll test this, but I believe that we tested this ages ago > and it did not fix > it. I believe you are not understanding text mode correctly > under Win*, since > that is supposed to treat CR/LF as \n and automatically > upgrade CR => \n for > you. On output, text mode under Windows will always give you > CR/LF, so if you > are doing anything different in the fprint(), you are causing > the problem > yourself. I'll bet dollars to donuts you have a \r in the fprint(). > > John > > -- > John Peacock > Director of Information Research and Technology > Rowman & Littlefield Publishing Group > 4720 Boston Way > Lanham, MD 20706 > 301-459-3366 x.5010 > fax 301-429-5747 > > > ------------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > > Web Archive of this list is at: http://search.smithmicro.com/ ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/
Scott Anderson
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
Version 4 (2000)
Physical Security for WebCatalog Directories (1997)
WebCat2 beta 11 - new prefs ... (1997)
Limit on nested [ShowIf]'s? (1997)
WebCat2 - [format thousands] (1997)
F3 crashing server (1997)
SiteGuard Admin Feature ? (1997)
Multiple fields on 1 input (1997)
Nested tags count question (1997)
Deleting associated records from 2 different databases (2001)
Submit buttons not working.... (1999)
[delete] problem (1997)
Wishlist;: Was Runtime version ... (2003)
Seattle based Webcatters? (2000)
RE: OK, here goes... (1997)
Off Topic: Frames Killer? (1998)
Cancel Subscription (1996)
Lookup Notfound (1998)
No Line Breaks from OSX server (more) (2002)
2.0 Beta (1997)