Sabahattin, I am a bit puzzled. None of the Braillenote List e-mails in my mailbox fits this description. Indeed, all of these e-mails are formatted. I use the Braillenote BT 32 having Keysoft Version 5.1 Build 22. I Also use Microsoft Outlook at one location, and Microsoft Outlook Express at another location. Using Microsoft Outlook, a test print of a randomly selected e-mail from this list prints perfectly on a laser printer.
Would you send me, off list, an example of what you are describing? Jerry Weinger Off List Replies: [EMAIL PROTECTED] -----Original Message----- From: Sabahattin Gucukoglu [mailto:[EMAIL PROTECTED] Sent: Thursday, August 05, 2004 10:46 PM To: Braillenote List Subject: Re: [Braillenote] Full Text Search Archive Hi Dean, On 6 Aug 2004 at 11:51, Dean Jackson spoke, thus: > Can you please advise us what exactly is the issue here? there are a > couple of things your email could refer to, hence the question. You might > also give us an example if you've discovered a complex issue. This is the issue where BrailleNote does not wrap its lines in messages. Netiquette and the limitations of certain mail user agents or transports mean that line lengths should not exceed 75-78 characters. RFC 2822 places a 998-character limit at the absolute maximum but recommends the 78- character limit (not counting CR/LF, making 80 total), but BrailleNote just writes lines until terminated by the user (i.e. each paragraph is given a stream of characters, terminated usually by two CR/LF pairs). This is causing corruption over here, where my mail transport is sternly refusing to let me have lines longer than the 998-defined limit (actually, I think it's a bit more generous than this, but I know the author refuses to go further for security and compliance reasons - I've asked), instead forcing a newline wherever it is necessary, normally resulting in lines and words getting chopped at inoportune moments. Some people here are using text-based user agents that abide by the 80-25 dimensional display and so don't much like the wrapping, this is true even for modern graphical viewers like Mozilla where an option is provided for wrapping malformed plaintext lines. The other, and far worse issue, is that of transports which simply trunkate lines beyond the limit. For this reason I am enquiring whether the wrapping of lines, as per the recommendations of RFC 2822, has been addressed, as I do feel it sufficiently important. Previous messages about this problem have visited the list before. An example of a malformed message can be had by making a BrailleNote send anything longer than 80 characters in a single paragraph - most messages on this list. Such messages will not look nice over here and will have words split by newlines, which my user agent then cleverly reassembles by substituting the newline/carriage-return with a space (it estimates how the lines should look, you see). Still perfectly horrible, though, with split words in the middle of sentences, and non-compliant. It may be that you will not spot these malformations because your transport doesn't enforce the limit (most Windows transports and the most modern and up-to- date UNIX transports, such as Sendmail) - try saving the message as a flat file and then examining it with a BrailleNote or hex editor, and you'll see what's happening. It's so-called "Paragraph mode", when it should really be "Line mode" with a right margin of 78 - 75 is best, allows for quoting characters. If you're still not sure what I mean or haven't found the trouble ticket, feel free to write back and I'll try to be a bit more clear. I wouldn't know whether this issue has been resolved in 5.1 because I rarely use the email program, and I can't infer it from the list although I still get these malformed messages. If you want to see a message as I see it, let me know and I'll encode one such message using MIME BASE64 encoding and send it to you - you'll get it without corruption because it was transported in a flexible encoding that works even with the limit in place and which all mail programs understand. Incidentally, that's one possible resolution (though I don't recommend it, because it theoretically narrows the audience of BrailleNote's email) - you could make BrailleNote encode the mail before it was sent in a suitable encoding method like Quoted/Printable, which is also designed to work with the RFC 2822 limitation, if you didn't prefer BrailleNote users to be purist netizens and wanted the benefit of long lines in email (even Microsoft don't, Outlook Express wraps by default, though it didn't used to). Cheers, Sabahattin -- Thought for the day: Intuition (n): an uncanny sixth sense which tells people that they are right, whether they are or not. Sabahattin Gucukoglu Phone: +44 20 7,502-1615 Mobile: +44 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
