Sabahattin, a slight correction. When you're writing an email to be sent, its contents are placed in a file called Mime Tempddtxt. This file is also found, like the Wp Tempddtxt file, in the root directory of the KeySoft System Disk. When you open a message from one of the KeyMail folders to read, the contents of this message are stored in the Wp Temp.txt file, not the contents of a message you're preparing to send. The Mime Temp.txt file itself remains the same, but its contents are overwritten each time you write a new message. FYI: I just tried renaming both the Mime Temp and Wp Temp files as RTF, and what happened was that the RTF files weren't overwritten, but that new .txt files were created. Basically, there were Mime Temp.rtf, Mime Temp.txt, Wp Temp.rtf, and Wp Temp.txt files in the root directory of my KeySoft System Disk instead of just Mime Temp.txt and Wp Temp.txt. Also, I tried changing the Presentation Style from "Paragraph" to "Linear" in an email I was writing, but this did not retain in the email when I received it back (I sent it to myself just for the purpose of testing this), and the Style had just gone back to Paragraph. I also tried changing the Style in the Mime Temp.txt file itself, but it doesn't work either, and the Style of the email just goes back to being Paragraph. Sorry that didn't help you, but I just thought you might like to know. Thanks. Maria
>----- Original Message ----- >From: "Sabahattin Gucukoglu" <[EMAIL PROTECTED] >To: Braillenote List <[EMAIL PROTECTED] >Date: Thu, 08 Apr 2004 22:18:29 +0100 >Subject: re: [Braillenote] Hey guys, use your spell checkers! >Hi Ann, >On 8 Apr 2004 at 8:50, Ann Parsons spoke, thus: >[...] >> I do wish that the BN could be induced to write in wrapped lines for >> email. Can't it be told to send txt with line breaks? >Nope, apparently not. It apparently uses so-called "Paragraph mode". >However much you fiddle with it, it don't work. It does write the message >you are preparing into the file named wp_temp.txt in the KeySoft System >Disk, which is written by KeyWord and then read by KeyMail. Perhaps doing >something to this file directly may help. Then again, perhaps it just >won't work, especially if KeyMail will just overwrite it with a new file >as soon as you begin your message. In summary, its rank with risks, and >wants PDI to look at it. >I've had a word with the author of my mail system and he is, >unsurprisingly, flatly against changing his server when: >A. Rules say strictly not to (see RFC2822, Sec. 2.1.1, reproduced below), >and >B. Preserving line ending for use in paragraph text can be achieved, and >the line length limits thus circumvented, by using any of a number of >encoding schemes (notably, MIME Quoted/Printable - see RFCs 2045, 2046 and >2049). >In the interests of backward compatibility, I strongly suggest that PDI >adopt the former approach and take the recommendation for the insertion of >CR/LF at or about the 75-78 character position as implied by this >document. >-- RFC2822 exerpt Begins -- >2.1.1. Line Length Limits >There are two limits that this standard places on the number of characters >in a line. Each line of characters MUST be no more than 998 characters, >and SHOULD be no more than 78 characters, excluding the CRLF. >The 998 character limit is due to limitations in many implementations >which send, receive, or store Internet Message Format messages that simply >cannot handle more than 998 characters on a line. Receiving >implementations would do well to handle an arbitrarily large number of >characters in a line for robustness sake. However, there are so many >implementations which (in compliance with the transport requirements of >[RFC2821]) do not accept messages containing more than 1000 character >including the CR and LF per line, it is important for implementations not >to create such messages. >The more conservative 78 character recommendation is to accommodate the >many implementations of user interfaces that display these messages which >may truncate, or disastrously wrap, the display of more than 78 characters >per line, in spite of the fact that such implementations are non- >conformant to the intent of this specification (and that of [RFC2821] if >they actually cause information to be lost). Again, even though this >limitation is put on messages, it is encumbant upon implementations which >display messages to handle an arbitrarily large number of characters in a >line (certainly at least up to the 998 character limit) for the sake of >robustness. >-- Exerpt Ends -- >RFC2822, Resnick, P. (editor), "Internet Message Format", April 2001 >This document is on the standards track. Retrieve the full text from a >number of repositories around the world. In the US: >http://www.ietf.org/rfc/rfc2822.txt >ftp://ftp.rfc-editor.org/in-notes/rfc2822.txt >For more information about RFCs and the standards process, visit the RFC >Editor at http://www.rfc-editor.org/ . >Cheers, >Sabahattin >-- >Thought for the day: > The only thing that hurts more than paying income tax > is not having to pay income tax. >Latest PGP Public key blocks? Send any mail to: ><[EMAIL PROTECTED] >Sabahattin Gucukoglu >Phone: +44 (0)20 7,502-1615 >Mobile: +44 (0)7986 053399 >http://www.sabahattin-gucukoglu.com/ >Email/MSN: <[EMAIL PROTECTED] >___ >To leave the BrailleNote list, send a blank message to >[EMAIL PROTECTED] >To view the list archives or change your preferences, visit >http://list.pulsedata.com/mailman/listinfo/braillenote ?
